On Wed, 3 Apr 2002, Jesse Erlbaum wrote: > > I don't agree. Judiciously scoping application modules is one of the > cornerstone concepts in CGI::Application.
I originally tried to design Cascade ( http://summersault.com/software/cascade/ ) by grouping functionaly according to the needed authentication level. This fell apart quickly though, because many run modes needed to be run by different kinds of users. I ended up redesigning the structure more around functionality and that worked better for me. I did try something like Jesse suggests of having different instance scripts for admins and public users, which perhaps might access the same code, but with different authentication requirements. That didn't work out well either for me because I had a lot of links to other run modes, and if I linked from admin.cgi to something accessed through public.cgi, which didn't authenticate me, then the administrative specific features went away. In the end, I ran everything through a single instance script, while trying to break up the modules used by functionality, ideally only loading the ones I needed as needed. The setup routine looked up the autentication needed for the run mode requested in a config file, and redirects the user for registeration if they need to be logged or need additional permissions to view the run mode. This at least keeps authentication related code out of the run modes. If it all sounds a bit messy, it is. Jesse's idea of handling authentication at a level beneath (above?) the application is appealing and is something I would likely try if I was operating in a mod_perl environment. As Cascade grows, I'm thinking about breaking it out into multiple instance scripts again, but I haven't gotten around to architecting exactly how that would work. -mark http://mark.stosberg.com/ --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
