Timothy Appnel wrote:
> On 12/12/05, Michael Graham <[EMAIL PROTECTED]> wrote:
>
>> PREFIX => 'MySite',
>> TABLE => [
>> 'blog/:rm' => { app => 'Blog' },
>> 'admin/:app/:rm' => { prefix => 'MySite::Admin' }
>> 'get/:path' => { app => 'GetDoc' }
>> ':app/:rm' => { }
>> ],
>
>
> PREFIX is optional in Dispatch. What is the harm in this?
>
> TABLE => [
> 'blog/:rm' => { app => 'MySite::Blog' },
> 'admin/:app/:rm' => { app => 'MySite::Admin' }
> 'get/:path' => { app => 'MySite::GetDoc' }
> ':app/:rm' => { }
> ]
This won't work as intended because the 'admin/:app/:rm' rule can't work with
multiple apps under the 'MySite::Admin' prefix. In order to make this work with
a non-overridable PREFIX, he'd need to make an entry for each app class under
the 'MySite::Admin' namespace, which could get kinda tedious.
I personally think that being able to override things like PREFIX, on a
case-by-case basis would be a good thing.
This also brings up another question. If a rule has ':app' in it, should a
warning/error be thrown if the right-hand side has "app => 'Foo'" in it? If not,
what should happen?
>>So while these are duplicates:
>>
>> 'blog/:year/:month?/:day?' => { app => 'Blog' }
>> 'blog/:page' => { app => 'Blog' }
>>
>>these aren't:
>>
>> 'blog/:year/:month/:day?' => { app => 'Blog' }
>> 'blog/:page' => { app => 'Blog' }
>>
>>In the second case, /blog/2002/12 matches the first rule, but /blog/2002
>>matches the second.
>
>
> I had to read your example three times before I understood why which
> is what I'm getting at. This still seems too confusing. It seems to me
> there has to be a better way or perhaps, in order to support what you
> propose, some form of simple regex pattern matching is required to
> disambiguate URL patterns like in your first example. This way :year
> can be defined as 4 digits (\d{4}) and will let single parameters fall
> to another rule. Rails has such a feature in their routes. That left
> side could get really gruesome looking if your patterns are complex
> enough.
We've already talked about using regexes on the left hand side in previous
emails and here are the main reasons against that:
+ regexes don't allow for named captures. You couldn't have it automatically
know which part of the match was the :app or :rm if any. This would require
inventing a new synax for that and then created our own regex parser to deal
with it
+ regexes are uglier. Not an important reason, but a reason non-the-less.
Regexes are their own mini-language, and no one will deny that they can be
pretty complex and sometimes confusing. We feel that all cases could be handled
by the syntax that's been proposed.
--
Michael Peters
Developer
Plus Three, LP
---------------------------------------------------------------------
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]
