On Tue, 04 Dec 2001 14:27:13 -0500, Mark Stosberg <[EMAIL PROTECTED]> wrote :
> Ok, I think I've run into something like this. I spent a lot of time > figuring out a fancy CGI::App internal way to do it, and then I finally > settled on this: > > Instead of calling the second run mode internally, I call it externally, > by issuing an HTTP redirect with a query string. It's still roughly the > same logic of "go to this other place in the application", > just a little bit different execution. I found that this method makes > debugging easier because the path from life to death of the process is > shorter-- It's now broken it into two "life cycles", one for the first > run mode, and one for the second run mode. The redirect approach was my first thought, cause that's what I've done in past applications, but I'm not a huge fan of it. For one thing I prefer POST to GET. Query string manipulation is a common security vulnerability, and while I always try to protect against it, hiding the query string adds a little (albeit very little) bit more security (I never try hacking a POST app when I can mess with someone elses GET app instead =). In addition, I'm making use of the Apache::Session modules, so I need to pass the session id around between executions. With your 'runmode/redirect/runmode/print' solution the first runmode would need to be responsible for ensuring that the session id was included in the get string. In my 'runmode/runmode/print' solution, the session id is added via TMPL_VAR to the template that gets wrapped around the entire output, at the instance script level. Basically, the way I do things, alot of core application functionality (session management, user authentication, common look, language preference, database connection, query_string parsing, etc) is encapsulated at a level seperate from the modules that actually do the work. The modules follow a very simple API, that wraps around CGI::App's (inherit from a base class, return don't print, etc). People (interns) writing the functionality just have to worry about the 'content' of the final application screen. Anyways, like I said, I'm gonna sub-class CGI::App. =) Thanks. Christopher [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
