> === 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').
How about this instead?
:year:(\d{4})/:day:(\d{1,2}/:month:(\d{1,2})
Sure it's ugly, 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' },
(Hey, when I formatted it like that, I fixed a bug in my sample code!)
And without comments we can get rid of a little bit of line noise:
':year:(\d{4})
/
:day:(\d{1,2}
/
:month:(\d{1,2})' => { app => 'Blog' rm => 'by_date' },
We could try parsing the comments ourselves, but that way leads to
madness and despair...
> === More about setting "value => undef"
>
> Given a pattern like this:
>
> ':year/:month/:day'
>
> We need to know whether ":month" and ":day" are optional or required. In other
> words, should this work?
>
> ':year/'
I'm reading that as: should '/1999' work?
My reading is that it shouldn't match (with or without the requirements),
because it's missing slashes. However '/1999//' would be ambigous, at
least without requirements.
But if the idea is to provide more matching logic to the routing system,
then maybe a different syntax could be used for optional parameters?
':year/?month/?day'
After all, isn't one of Perl's superpowers the ability to solve problems
with punctuation?
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]