On 2005-12-08, Webmaster Techcode.NET <[EMAIL PROTECTED]> wrote:
>
> But I'm a bit lost on the point on this - the only benefit I see
> compared to doing this by just .htaccess/mod_rewrite (which you need
> to use anyway) - is that you can generate the links [ such as:
> url_for( controller => 'Blog', rm => 'recent' ); ]
You don't need mod_rewrite, it just helps send everything through the
dispatcher. Without out all the URLs could go through a script that
might be
/dp.cgi/app/rm/42
Instead of
/app/rm/42
Also, there is increased portability without a mod_rewrite/Apache dependence.
Finally, we should underestimate the developer usability of writing
dispatching in /Perl/ rather than mod_rewrite voodoo.
For me, working with mod_rewrite is in the same realm as editting
procmail syntax... I only do it when I have to, and usually with a
reference handy.
> Anyway in the nature of true (lazy) programmers I'm also interested in
> a solution that would enable you to work the magic without specifying
> the dispatch map. Say similar to AutoRunmode module ...
Rails already handles this idea. You simply start with a generic map:
":app/:rm/:id"
And then add exceptions when you need them.
> In a similar way as the Dispatch modules works (first part is module,
> second is runmode/method). We could just stuff the rest of the params
> inside url as matching name value ...
>
>==== Sample ====
>
> www.site.com/Module/Method/param_name/10 or
> www.site.com/Module/Method/param_name=10
>
> Would dispatch to Module (include some prefix if applicable), call
> it's Method sub, and set param_name to 10 ...
No, thanks. That's what query strings are for.
The dispatch mapper does allow you to leave out query parameter names
from the URLs, but using that more than one two things can quickly lead
to ugly URLS
/foo/23/45/452
( Putting dates an URLS an exception, as we are trained to see that pattern. )
If you want to put names *and* values in the URL than that's what query
strings are for.
I have now integrated the comments from the wiki into the main design
document. I removed the comments that fully integrated, but I left two
of Shawn's because I'm not sure my responses would fully address the
concerns.
Here's what I said:
=== 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.
=== 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/'
To make the distinction, we either need to make some fields as optional, or
some as required.
Here we follow Rails precedent of defaulting to required, and being explicit
about being optional. Think of it as defaulting to "use strict" for URL
patterns.
Mark
---------------------------------------------------------------------
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]
