On 12/12/05, Michael Graham <[EMAIL PROTECTED]> wrote: > > > So, essentially, CA does the following upon being used: > > 1) Load all the plugins requested. Each plugin will register as being > > used for a specific purpose (which could be "I add methods"). > > 2) Verify that all required steps (such as dispatching) have a plugin > > loaded or load the default one. > > I find this interesting in an academic sense, and I'd like to see these > ideas fleshed out further. At the moment my immediate questions are: > > * Will this lead to more fragmentation of styles or greater > standardization?
The question doesn't make sense because it doesn't matter. The point is that, just as Apache2 defined the 18 steps it takes in generating a response to a request, CA should define the N steps it takes to do its thing. Whether you choose to do the simple thing, the complicated thing, or the thing CA4 does ... that's your business. I see this as the true tinkertoy approach that CA initially held out to me. > * Are there there specific things that are hard to do now that should > be easier, or is this more of a conceptual cleanup? This idea sprung out of the routes/dispatch discussion. If this were in place, the discussion wouldn't include "How do we hook this in?" Also, this would make a lot of plugins easier to write. For example, CAP::TT would use the exact same syntax as CAP::HT (which would be the default). > * How do subclasses work? When you've discovered which module is > going to handle a request, do you 'rebless' the current running > application into that module's namespace? Or does the dispatch > stuff happen at the class level before the app is run? Well, it currently happens in the run() method in CGI/Application.pm. I don't see any reason why the proposed steps-to-run would require any change other than where the code the fulfills that step lives. > One thing I can imagine might be possible with a system like this is > being able to do initialization (db, config, log, etc.) before dispatch. > > For instance, at the moment it's hard to read your dispatch table from a > config file, because configuration isn't initialized until runtime. Since the code that fulfills each step can live wherever you want it to, that's perfect. :-) Rob --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
