>
> > I know, I know. I've been wondering how I missed this for so long ...
> > it has made developing web applications fun again!
>
> Yes, really!
And my application reuse has gone up astronomical amounts!
> > The 2.3 release does not provide this functionality, AFAIK.
> However, that
> > doesn't mean 'cgiapp_prerun( )' or 'cgiapp_init( )' can't be
> useful to you.
>
> I've looked at the code and found that the run_mode is calculated before
> calling the pre-run hook, and there is no way to tweak it there.
>
> > What are you trying to achieve?
I have just finished this functionality last week.
> I need a way to handle sessions automatically. And I thought I can do
> it this way:
>
> - add two 'standard' run modes (new session, check session);
Are those run modes or operations leading up to the run-mode?
> - use pre-run hook to check for the existence of a session;
> if there is no session, change run mode to new session;
I do that, but instead I die, my exception handler prints redirects to the
login C:A for failed sessions.
Is this something you can handle by passing it off to your error handler
instead of trying this run-mode magic? Changing (or redirecting) to a run
mode to handle this event was my first attempt as well, but I found using
die( ) and exceptions a much cleaner way.
> - inside new session create a new session, save original request,
> and call (via redirect) run mode check_session;
You do not provide any type of 'login' or 'authorization' before setting up
your sessions?
> - in check_session check if the cookie is there; if so redirect
> to the original run mode (restoring all saved parameters);
> else show some error.
I haven't done this, so I can't comment.
> I use cgiapp_init to pre-load the 'standard' run modes and avoid repeating
> myself in every application. I don't know if there is a better way to
> pre-load run modes, but it works.
You can use 'super-classes' to provided shared features (functionality
layers) but they do not provide 'shared run mode' support. My thoughts
(after a while in C:A) is that reuse and maintainability are highest when we
do not build monolithic C:A, but instead break our functionality into
separate, reusable web objects. Thus, I have
CGI::Application::WebService::Login, CGI::Application::WebService::Logout,
CGI::Application::WebService::SimpleIndex, CGI::Application::Notes::Editor,
ect.
> All applications inherit these methods from Apps::Base, that is of course
> a subclass of C::A.
Subclassing works very well to help alleviate the need for common run modes.
> I know that sessions can (and should) be handled by Apache, but
> the current deploy environment does not permit any mod_perl.
And depending on one particular webserver lowers your application's
portability (*ducks*).
> All hints to do this in another way are welcome!
The way I'm looking at this is that we use sub-classes to share
functionality layers between groups of applications that both need the same
functionality, and divide applications into more reusable components, and
build the application out of cooperating C:As instead of one larger C:A.
Now, this might seem the best way for me, due to project requirements, since
what I'm building is more of an application server than a CGI script,
however, I feel the lessons I'm learning are applied to your problem as
well.
Since you are not using Apache::Session (or I guess CGI::Session) are you
rolling your own (like me) session manager module?
--- Cory Trese
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
