Timothy Appnel <[EMAIL PROTECTED]> wrote:
> On 12/12/05, Michael Graham <[EMAIL PROTECTED]> wrote:
...
> Prefix is a nice short hand when all
> modules share the similar names, but it complicates matters when you
> are dealing with modules from completely different namespaces.
Which is why you don't use 'prefix' when you really mean 'app'. That's
why I gave examples of both:
'admin/:app/:rm' => { prefix => 'MySite::Admin' }
'get/:path' => { app => 'GetDoc' }
In some cases (when you have a bunch of modules under a namespace), you
want to use a prefix. In other cases you don't even want to derive the
module name from the URL.
The reason I want to allow 'prefix' in the results section is because
sometimes a dispatcher sits in front of more than one namespace.
> This feels like a fringe case to me.
Well, it may seem esoteric to you, but the examples I gave are pretty
close to what I use every day.
> > Yes, but these examples are deliberately contrived to illustrate the
> > mechanics of the mapping system, and the various edge cases. They are
> > not meant to be real world examples. If you used a mapping like the
> > above in real life, you get what you deserve, IMO.
>
> I don't see these are being edge cases since your scenario it
> precisely how Movable Type constructs its URLs by default. Not to say
> that we're going to build MT here, but that your example URL scheme is
> not that exotic or outlandish.
I don't have an MT system handy to test with, but I do want to point out
that that we're only talking about *optional* parameters. There is no
ambiguity here:
'blog/:year/:month' => { app => 'Blog' }
'blog/:id' => { app => 'Blog' }
> I'm either for really simple or going all the way (i guess that would
> essentially be a port of what Ruby's Routes does) with really simple
> being my overwhelming preference. What you are advocating is between
> the two and seems more incomplete then a compromise.
Well that seems a bit like all-or-nothing thinking to me. The syntax
I've been promoting is good enough to handle all of the mapping
scenarios that I've had to deal with, so I can't say it seems
incomplete to me.
You seem to have latched on to a very small aspect of the system, namely
the it's possible that programmers will shoot themselves in their feet
by accidentally entering duplicate rules. I suspect that this is going
to be a trap with *any* system that involves matching.
For instance, using your proposed syntax:
'blog' => { app => 'Blog', params => ':rm' }
'blog/admin' => { app => 'Admin', params => ':rm' }
What does 'blog/admin' match? By your reckoning it should be *obvious*
that it matches the first rule, but it isn't obvious to me.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
---------------------------------------------------------------------
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]
