On 2005-12-11, Timothy Appnel <[EMAIL PROTECTED]> wrote: > > The CGI::Application::Dispatch POD says "Any extra params to > dispatch() will be passed on to the new() method of the > CGI::Application module being called." I think this covers what you > are asking for. Correct?
Thanks. I had missed that. It would be helpful to add an example of that the synopsis to make the functionality easier to discover. This does handle the default args_to_new() case. I would still like to be able to make exceptions for each module. I have started setting different TMPL_PATH values in different instance scripts. > If we are going to support such a thing then we should just support > regular expression matching and be done with it. My preference is to > tackle these other things first, release and see how things go before > returning to this. I wouldn't mind incremental updates here, although I am fond of the proposed dispatch syntax. > Here is my scenario to how the dispatcher could work. Treat every path > as $app/$rm/@params. The dispatcher loads the $app and is defined > executes the run mode. The dispatcher would stash the remaining > elements (@params) for the run mode to optionally do something with. > The run mode would then assign, validate and handle errors. That's essentially what we already have now with @params being handled as the query string. One of the essential features is to provide a name for part of the URL in the dispatcher, and than have easy access to that named parameter in the run mode. The "optional" versus "required" seems less important but nice. > To me this is a lot more straight forward and lightweight then > creating an entire syntax to perform these functions IF you need them. You make it sound as if we creating a large and heavy syntax. We are talking about two special characters: ":foo" indicates a named URL part named foo "?" means the previous named param is optional. Here: I went ahead and created a proof concept for parsing this, including 7 tests: http://mark.stosberg.com/perl/ca-dispatch.pl > CGI::Application::Dispatch->dispatch( > PREFIX => 'MyApp', > DEFAULT => 'foo', > config_files => ['../../../config/Config.pl'], > TABLE => { > 'bar' => 'Some::OtherName', > 'foo' => [ 'Some::OtherName', 'store' ], > }, > ); This doesn't work for me because it doesn't cover the named the params. It also removes the names in the hash, which added some clarity. It's not so clear that the second element is a run mode name. (Especially after I edited your example above to rename the run mode to something else besides "run_mode" . :) Stepping back, I want to say I'm satisfied with how this design-by-consensus is going. In designing a shared framework, we have a few options: 1. Bury our heads in the sand and ignore what other frameworks are doing. 2. Blindly follow what other frameworks are doing because it seems to work for them. 3. Visit the foreign lands the of other frameworks and critically review the differences to decide what to keep, discard and change. We clearly taking the third option. Having been a part of formal consensus based decision making groups, I can see that making decisions this way tends to take longer, but is more likely to lead to results the group is satisfied with. (And yes, given a large enough group, the model breaks down.) Differences have been aired, but the tone has been respectful and I think it's been a valuable process. Mark -- http://mark.stosberg.com/ --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
