On 12/11/05, Mark Stosberg <[EMAIL PROTECTED]> wrote:
> That's essentially what we already have now with @params being handled
> as the query string.
I was thinking of something in the path_info that doesn't have a key
affixed to each value. As in @params = ('2005','12','25').
> 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.
Understood. How would this scenario handle naming conflicts -- there
is a form element named year and a path_info/dispatch parameter named
that. That wasn't discussed in the Rail documentation. The easy answer
is don't do that, but it should be stated.
> 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.
I get the feeling something is throwing me off that is clear and your
head. I think its mixing the param ordering with the prefix/key. Like
this scenario handle posts/:category and posts/:year/:month?/:day?. Is
it simply he who comes first wins meaning if category comes before
y/m/d that year alone will never work because category will intercept
it?
To say the syntax is heavy isn't accurate and I apologize if I gave
that impression. I'm thinking about all of the potential exceptions
you may need to handle or ways you could shoot yourself in the foot.
Perhaps seperating variable assignment from the prefix will clarify
the matter. The fact I have a problem is clear here:
TABLE => {
'posts' => {
app => "SomeModule',
params => ':year/:month?/:day?',
run_mode => 'date_archive'
},
'posts' => {
app => "SomeModule',
params => ':category',
run_mode => 'category_archive'
}
};
Basic Perl knowledge tells you this won't work because you have two
hash elements with the same key.
Slightly off topic: if a run_mode is not defined in a table mapping
element is the second path_info param automatically picked up as the
run mode or must that be defined in the variable assignment? In other
words given this...
'posts' => {
app => "SomeModule',
params => ':category',
}
Would /posts/view/news load SomeModule and call the view run mode
while assigning the value "news" to param('category')?
> > 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" . :)
I was trying to keep it as close to the existing
CGI::Application::Dispatch. Since I was only envision a second
optional param being added it seemed unnecessary to introduce a hash.
(I've been working with a few modules like XML::Writer lately that
follow such a convention.)
> Differences have been aired, but the tone has been respectful and I
> think it's been a valuable process.
Agreed.
<tim/>
--
Timothy Appnel
http://www.timaoutloud.org/
---------------------------------------------------------------------
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]
