Brett, > I'm unclear on what is wrong with the suggestion I made the > last time this > issue was raised: > > write a subclass of CGI::App that adds the > dynamically_choose_next_screen() routine above, which uses a > variable set > in setup() via run_mode() and start_mode()-like routines. Make all of > your apps subclasses of this. >
This was a very good suggestion and I DID implement it from the last time the issue was raised. The problem is that you get an extra set of headers (see the subject line). > Granted, you'd have to manually put said return call in your > non-outputing > modes, but that seems minor. If you disagree, you can > overload run() to > call run_mode(), then output the results of output_mode(), though that > would remove the easy upgrade path when CGI::App gets upgraded. > > Viola. So then I decided to overload run() exactly as you suggest here, but now my problem is I don't have an easy upgrade path when CGI::App gets upgraded. Where have I heard that before? :-) The bottom line is that I am asking for the breakdown of run() into run_mode() and output_mode() to become a permanent part of the module. Then I can overload run() without losing much at all in the way of upgrade ease. That is all. Elizabeth --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
