On 10/14/05, Aaron Trevena <[EMAIL PROTECTED]> wrote: > > > Sessions: > > > > > > I want to add a skeleton get_session method, that is called before > > > authentication (so that authentication can check session info if > > > available), it will just provide an empty session object attribute > > > that, like the authenticate method is overloaded by plugins or > > > drivers. > > > > I'm not sure what this achieves? Unless you define the semantics of the > > attribute, what does it offer that a plugin like > > Maypole::Plugin::Session doesn't? > > That's just it - it provides a standard hook in the controllor for > fetching the session, either through a plugin or user written code. > This is how authentication works nicely both with plugins and your own > code. > > Simon Cozens agreed it was a nice way to do it - essentially the > default solution would be in the manual rather than the code as it's > not a problem you can solve in a general enough case to put in the > core and expect to work out of the box. >
I used to be against the proliferation of special-purpose hooks, on the grounds that I don't want to try to predict everything that people might need. Instead, generic hooks at different points in the request cycle seemed theoretically better. On the other hand, providing special-purpose hooks for common usages will keep code simpler. I'd still like to see generic hooks added though. We might have prepare_request ** get_session ++ get_user ** start_request ** is_model_applicable xx authenticate authorize ** additional_data [ run model here - if applicable ] fixup ** [ process view here - if necessary ] end_request ** [ send headers and output here ] cleanup ** ** proposed (daveb) ++ proposed (Aaron) xx in svn others already exist It's a lot of hooks, but I think since Maypole is a framework, we should offer plenty of hooks. There's no backwards-compat problems with adding these, although it would be nice to re-engineer Mp-P-USC to use these hooks. Currently, it plugs into authenticate(), from where it calls its own get_user(), which as well as fetching the user, also sets up the session. Lots of independent things going on, which makes it a complicated plugin. prepare_request(), end_request() and cleanup() would be useful primarily for logging and/or timing. cleanup() might also be useful for mod_perl apps that might need to cleanup at the end of each request (I've named it for the mod_perl method of the same name). fixup() is Peter's proposed additional_data2(). Don't really like either name, but I like the hook. An advantage to having these hooks is that it makes documentation easier. Instead of explaining how to hook into authenticate() to do stuff like fetching a session, a user, authenticating the user, and then authorizing the user, all at the same time, these are all separate calls. And we don't need to explain how to hook into authenticate() to do any other stuff you might want to run early in a request - use start_request for that. d. ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Maypole-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/maypole-devel
