Jesse,
Thanks for your recent proposal re: "cgiapp_preoutput". I think it
generally addresses the desire to "do something else" in between running
and producing output. As I understand it, this something that is defined
once per module. One seems more useful the ability to do something
different here once per run mode. I imagine that cgiapp_preoutput could
contain a switch statement in it, so that it did different things for
defined run-modes, but I think I would find that logic design less
clear.
Thinking back to my own proposal for "return_rm()", I realized that case
where I used eval() could be handled a couple of ways within the current
CGI::App framework without using eval():
1. For a small number of possible "return run modes", I could pre-define
this options each as it's own run mode:
save_data_return_to_mode1
save_data_return_to_mode2
Each of these run modes might be very simple (and similar!):
sub save_data_return_to_mode1 {
$self = shift;
&save_data;
return $self->mode1;
}
That works, but it would mean a lot of repetitive code.
2. For a large number of possible "return run modes", I could possibly
call the other modes "externally", by redirecting to them through the
browser, and passing a query string.
I don't need eval() for that, or multiple pre-defined run modes, but I'm
limited in that I'm passing arguments through CGI instead of custom perl
data structures, as I could do with a direct call.
Of course, on the other hand, eval() works, and doesn't necessarily need
a replacement. :)
Ok, I didn't mean to come to a conclusion here, I just wanted to add
this to the discussion.
-mark
http://mark.stosberg.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
