Re^2: CGI::Application same function code

Thanks for your reply it contained some intresting new approaches some that I understood and some that I didn't.

I think I read somewhere on the C:A mailing list that you could only use a function name as a runmode, what exactly are you doing here:

start  => sub { shift->_runmode('start'); },
[download]

I understand that you call the _runmode function with the argument 'start' but besides that?? Could you send in other arguments, objects as well?

However, In the examples I still need to add the cgi object-, dbh code in the showStart function to be able to get the function specific code to work.

I somehow want my functions to inherit from one function that has all the basic code such as: self, cgi object, dbh, output etc.

Comment on Re^2: CGI::Application same function code Download Code

Replies are listed 'Best First'.
Re^3: CGI::Application same function code by Tanktalus (Canon) on Feb 13, 2005 at 16:05 UTC
You can use either a function name, or a code reference. (Trust me - my name is in there for providing a patch to this area.) By giving an anonymous sub here, I'm creating a code reference which gets passed in. Then C::A will call it something like: `$self->$function()`. This means that the first (and only) parameter is the C::A object, which above I shift off to use to call _runmode. You can send in anything else that is visible at the point you're setting up run modes. There is not really a lot of point to doing so in this case, however, since you can just as easily put all of that information into `$self->param()` and everyone else would have access to those as well. As for getting the CGI, DBI, and other objects/data, I don't think there is a better way than what you're already doing. What you're looking for is a templating mechanism (on CPAN, Source Filters - I've never used source filters, but just a casual read around here for the last month has shown a number of concerns around using them - they can be quite dangerous). This is not part of standard programming languages - in C/C++, you would need to use the preprocessor. In Perl, a source filter. Maybe something along the lines of a macro that you put in your code, "RUNMODE_SETUP;", which your source filter could catch and insert the real setup code. It does seem a bit overkill to me, and you do have to be careful, but it may work.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: CGI::Application same function code
by Tanktalus (Canon) on Feb 13, 2005 at 16:05 UTC

You can use either a function name, or a code reference. (Trust me - my name is in there for providing a patch to this area.) By giving an anonymous sub here, I'm creating a code reference which gets passed in. Then C::A will call it something like: $self->$function(). This means that the first (and only) parameter is the C::A object, which above I shift off to use to call _runmode.

You can send in anything else that is visible at the point you're setting up run modes. There is not really a lot of point to doing so in this case, however, since you can just as easily put all of that information into $self->param() and everyone else would have access to those as well.

As for getting the CGI, DBI, and other objects/data, I don't think there is a better way than what you're already doing. What you're looking for is a templating mechanism (on CPAN, Source Filters - I've never used source filters, but just a casual read around here for the last month has shown a number of concerns around using them - they can be quite dangerous). This is not part of standard programming languages - in C/C++, you would need to use the preprocessor. In Perl, a source filter. Maybe something along the lines of a macro that you put in your code, "RUNMODE_SETUP;", which your source filter could catch and insert the real setup code. It does seem a bit overkill to me, and you do have to be careful, but it may work.

[reply]
[d/l]
[select]