On 2005-12-10, Timothy Appnel <[EMAIL PROTECTED]> wrote:
> I'm coming in late and trying to catch up on this. After reading this
> entire thread I don't get a sense of consensus yet and have to wonder
> what the rush is. If there is one thing you take away from this
> message it's slow down and think this through ESPECIALLY if this is
> going to be added into the core.
There is no need for this to be in the CGI::Application core module.
Which means there is less need to agree, since it will be easy to /not/
use or use an alternate. It's still nice to discuss to come up with the
best possible design.
> I have to agree with Ron about featurities and over-engineering (my
> term). I'm big on doing the simplest thing possible that works. After
> scanning this thread and the wiki page I get the sense that the scope
> is too broad and ambitious which in my experience means it is likely
> to fail. Even with all forms of pattern matching removed this still
> seems like a bit much.
Having removed general pattern matching, this is a more modest
proposal than what Rails, Django and Catalyst implement.
> Let me come at this from a different direction. Is
> CGI::Application::Dispatch so deficient that it needs to be scrapped
> or receive a major overhaul? I liked it quite a bit (Nice work
> Michael. :) because I believe that if you have long complex URLs
> schemes to manage then you are doing something wrong. (That's my
> RESTful leanings.) It always did right by me. Besides limitations are
> fun and good for creativity. (A mantra of the 37 signals team I have
> to concur with.)
>
> Where is the discussion of what you can't do with
> CGI::Application::Dispatch? Why these missing features are essential
> (as opposed to nice to have). This isn't clear to me at all.
This is a good point to discuss how CGI::App::Dispatch fits into the
conversation.
- ::Dispatch doesn't handle the URL generation helper methods like
uri_for() and link_to(). (Not that these belong in a dispatching
module, but they are part of the bigger plan.)
- ::Dispatch doesn't handle "args_to_new", which is necessary to
completely replace an instance script.
- ::Dispatch doesn't handle parsing the URL for parameters. In the new
design you can specify ':year/:month/:day' and later easily access
the values from the URL in $self->param('year'), etc. Very handy.
Does ::Dispatch have a fatal flaw? No, that I can see. It seems like a
workable foundation.
Here's an attempt at merging the concepts together:
CGI::Application::Dispatch->dispatch(
# default prefix
PREFIX => 'MyApp',
# default args to new()
ARGS_TO_NEW => {
PARAMS => {
config_files => ['../../../config/Config.pl'],
}
},
TABLE => {
# Support the original Dispatch style
'bar' => 'Some::OtherName',
# plus the new proposal...
'date/:year/:month?/:day?' => {
app => 'Blog',
rm => 'by_date',
args_to_new => { TMPL_PATH = "events/" },
},
},
);
########################
Some nitpicks: I think it would clearer to have the "prefix" and
"args_to_new" wrapped in a defaults hash, as in the new proposal.
Also, I think "NS_PREFIX" is a little clearer than "PREFIX".
Mark
---------------------------------------------------------------------
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]
