On Wed, 08 Sep 2004 10:39:08 -0400, Michael Peters <[EMAIL PROTECTED]> wrote:
Unless you modify every run mode of every application module to save
their state before returning to the browser
In my particular application, this is fairly easy. All my runmodes call a common method that does some processing right before the runmode returns. So I'd only have to modify one place to save an extra hidden parameter or set a cookie.
What I had in mind was to have all the runmodes that need to save their state (this can be checked in the common end of runmode method) save it and then restore it when going back to the runmode.
remeber where they came from. And you preferences module could check for this parameter and redirect them to that url after they are done.
In some cases the amount of state information that would have to be saved would be more than the allowed length of a URL so I'm not sure this would work. Yeah, yeah, I know I should store this in a session variable somewhere but with my particular hosting set-up (which resides on a closed WAN) that's not trivial. It's far easier to pass the session info around in the web pages.
All you need in order to have sessions is a place to write files (a tmp dir of some sort) and CGI::Session can use it. You don't need a db or anything else.
I don't write CGI apps for a living and this is my first time using CGI::Application so I'm sure I've made some less than optimal design choices. However I'd like to get this to work without a major overhaul of the application. I could override CGI::Application::query and set the __QUERY_OBJECT myself but that's not guaranteed to work if CGI::Application gets upgraded. I could also modify each runmode to restore it's own state but with 29 runmodes, that's less than ideal.
Well, if you application knows which run modes need to save their state and which don't then it can also know which need to reinstate their state or not right? You don't need to modify all 29 runmodes to do this, just put in in your cgiapp_prerun().
I really don't have a problem with changing C::A's behaviour on this issue if you want to create a patch (code, docs, and tests) that would do this. How does everyone else feel about this? Is there a real reason for C::A behaving like this? If you get you patch up and ready then I might go ahead and make up the one for fixing TMPL_PATH/tmpl_path() handling of array ref too and maybe we can convince Mark/Jesse to make a new release.
-- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
