Timothy Appnel <[EMAIL PROTECTED]> wrote:
> On 12/11/05, Mark Stosberg <[EMAIL PROTECTED]> wrote:
> Understood. How would this scenario handle naming conflicts -- there
> is a form element named year and a path_info/dispatch parameter named
> that. That wasn't discussed in the Rail documentation. The easy answer
> is don't do that, but it should be stated.
Actually I don't think there will be a conflict, because the parameters
are accessed in different ways:
$self->param('year'); # from dispatch
$self->query->param('year'); # from POST
$self->query->url_param('year'); # from QUERY_STRING
...
> Like this scenario handle posts/:category and posts/:year/:month?/:day?.
> Is it simply he who comes first wins meaning if category comes before
> y/m/d that year alone will never work because category will intercept
> it?
Earlier on in this thread, I was speculating about how to disambiguate
between multiple matches, and I was quickly talked out of proposing any
kind of intelligent matching system (based on best match, longest match,
etc.). It's much, much simpler to make the first match win, and let the
programmer select an order that makes sense.
And you're right that if you have this mapping:
posts/:category
posts/:year/:month?/:day?
then the second one will never match. I suspect the system can be
designed to warn about mappings that can't be reached.
> Perhaps seperating variable assignment from the prefix will clarify
> the matter. The fact I have a problem is clear here:
>
> TABLE => {
> 'posts' => {
> app => "SomeModule',
> params => ':year/:month?/:day?',
> run_mode => 'date_archive'
> },
> 'posts' => {
> app => "SomeModule',
> params => ':category',
> run_mode => 'category_archive'
> }
> };
>
> Basic Perl knowledge tells you this won't work because you have two
> hash elements with the same key.
Ah! Thanks for this example! Something was bugging me about using
C::A's existing TABLE structure and I coudn't put my finger on it.
The TABLE structure won't work because it's a hashref. This is not so
much a problem because you can't have duplicates, but because you lose
the order of the entries. When that happens, you can no longer let the
first match win.
We need an array ref instead, something like:
DISPATCH => [
'posts/:category' => { app => 'Blog', rm => 'posts' },
':app/:rm/:id' => { app => 'Blog' },
],
> Slightly off topic: if a run_mode is not defined in a table mapping
> element is the second path_info param automatically picked up as the
> run mode or must that be defined in the variable assignment? In other
> words given this...
>
> 'posts' => {
> app => "SomeModule',
> params => ':category',
> }
>
> Would /posts/view/news load SomeModule and call the view run mode
> while assigning the value "news" to param('category')?
I think the run mode should only be taken from path_info when explicitly
requested by the rule (e.g. /foo/:app/:rm ).
For most apps I want the run mode set, but every so often I have an
exception, e.g:
/get/path/to/file.html
/get/other/path/to/other/file.html
For an app like this, I don't want the run mode being set to 'path' or
'other'. And I also don't want to be forced to make my URLs
artificially longer by including a dummy run mode:
/get/view/path/to/file.html
/get/view/other_path/to/other_file.html
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]
