Michael Graham wrote:
>>=== More notes about "requirements"
>>
>>Without requirements, the pattern ":year/:month/:day" could just as well match
>>"posts/show/10". With no requirements you either have to match on a fixed
>>string, or assume any characteres as a URL bit. requirements are not meant to
>>fully validate the URL bits. It is simply there to allow to provide
>>distinctions based on patterns to complete more flexible routing schemes
>>without having longer URLs.
>>
>>It's not essential feature to have for v1.0 and may be something we can live
>>without.
>
>
> Yeah, I can see how pattern matching can assist in routing. I guess
> that what bothers me about requirements is that (a) it looks like
> validation/untainting (which it's not supposed to be), and (b) it puts
> additional matching logic on the right hand side (which in my head is
> sort of for 'match results').
I'm not sure how flexible this needs to be. Thinking about it, I don't think
there will be a full url of "/1999/10/25" in a real site. It would probably look
more like "/article/view/1999/10/25".
So the default rule of "/:module/:rm/:id wouldn't match. The programmer would
probably use a rule of "/:module/:rm/:year/:month/:day", but even that is
probably too generic. It would probably be "/article/view/:year/:month/:day"
since the number of modules and run modes that can take a year/month/day combo
would be limited.
> How about this instead?
>
> :year:(\d{4})/:day:(\d{1,2}/:month:(\d{1,2})
>
> Sure it's ugly
Sure is.
>, but at least the matching logic is all in one place.
> Plus hopefully its ugliness discourages abuse. We can even allow multi-
> line commented maps (after a fashion):
>
>
> ':year:(\d{4})', # year, e.g. 9008
> '/',
> ':day:(\d{1,2}', # day, e.g. 99
> '/',
> ':month:(\d{1,2})', # month, e.g. 72
>
> => { app => 'Blog' rm => 'by_date' },
Even uglier in my opinion.
[snip]
> We could try parsing the comments ourselves, but that way leads to
> madness and despair...
That's crazy talk! But seriously, I think we need to keep it as simple as
possible (I want to avoid having a dispatch parser that implements anything
close to a full grammar). All it needs to do is cover the majority of the cases
at first. As more and more users try it out and discover real-world use-cases
where it's not sufficient and then we can look at doing more.
But in all likelihood, I suspect that most people will be able to find a way to
get what they want with just a couple more rules added in.
Another thing I would like to see is to be able to have this dispatcher be able
to work as either a PerlTransHandler (to dispatch to .cgi scritps) or
PerlContentHandler (to dispatch straight to the module) under mod_perl.
Maybe the rules are specified in a separate module or even in the httpd.conf. So
whatever package implements this dispatch table would include a module or two to
act as the handler.
--
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]
