> At the point that setup() is called, we do not know what the run-mode is. > In fact, the settings in setup() define exactly how we figure that out. > (See the mode_param() method, for instance.)
Yea, we had talked about this. We were not sure what type of changes to the objects the calls to '$self->run_modes( )' and '$self->start_mode( )' made. We speculated that an internal variable was set some place here we could check. > The "best" way to find out the run-mode in setup() is to check > whatever form > parameter you intend to define via mode_param(). Via loading the '$self->query( )' object and using it's '$query->param( )' method? This would work and not annoy any of the inner workings of C::A? > In general, however, it is best not to do something which would > require that > you need to know the run-mode during setup(). Instead, consider putting > that code into your run-mode methods. With some savvy object-orientation, > you can probably accomplish whatever goal you had in mind, via run-mode > methods instead of in setup(). > Our goal is to be able to create a 'superclass' to use to develop the rest of our system. The reasoning behind asking the C::A what run-mode it was going to run in 'setup( )' was so that we could validate the user's session and authorize them to run said run-mode. Failing authorization would result in a 'die( )' call, success in the run-mode being executed. Perhaps I didn't mean 'setup( )' perhaps I meant 'cgiapp_init( )' which is the method used for creating superclass. So I restart my question : At the point when execution is within 'cgiapp_init( )' I hope to find a way to harvest (1) a user cookie, (2) the run-mode we are accessing, (3) the parameter that the application was called with via the '.pl' script. Thanks again (Jesse especially!) everyone, Cory --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.vm.com/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
