On 2005-12-12, Timothy Appnel <[EMAIL PROTECTED]> wrote:
> On 12/11/05, Mark Stosberg <[EMAIL PROTECTED]> wrote:
>
>> That's essentially what we already have now with @params being handled
>> as the query string.
>
> I was thinking of something in the path_info that doesn't have a key
> affixed to each value. As in @params = ('2005','12','25').
For reference, Catalyst is a little more like this, although they put
the logic in run mode attributes, like this:
sub day : Regex('^(\d{4})/(\d\d?)$') {
my ( $self, $c, $year, $day ) = @_;
I like the centeralization, clarity and simplicity of where we are
headed as an alternative.
>> One of the essential features is to provide a name for part of the URL
>> in the dispatcher, and than have easy access to that named parameter in
>> the run mode.
>
> 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.
Query params would be in $self->query->param();
Path info params would be in $self->param();
(I'd really like to /not/ add yet another param() system).
>> You make it sound as if we creating a large and heavy syntax. We are
>> talking about two special characters:
>>
>> ":foo" indicates a named URL part named foo
>> "?" means the previous named param is optional.
>
> I get the feeling something is throwing me off that is clear and your
> head. I think its mixing the param ordering with the prefix/key. Like
> this scenario handle posts/:category and posts/:year/:month?/:day?.
No, our simplified system wouldn't handle that. Rails handled it by
restricting that ":year" must be a 4 digit number number. The most
recent proposal on the wiki removed that feature. The workaround would
be be
posts/:category
posts/by_date/:year...
That works for me. I think if URLs are just a little bit more magical,
I'll be happy.
> 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?
It will be an array where "first match wins".
> To say the syntax is heavy isn't accurate and I apologize if I gave
> that impression. I'm thinking about all of the potential exceptions
> you may need to handle or ways you could shoot yourself in the foot.
>
> 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'
> }
> };
I think it's important that the url patterns by the key, because
logically we are mapping URLs to something else.
> Basic Perl knowledge tells you this won't work because you have two
> hash elements with the same key.
>
> 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 "start_mode" would be used, unless there is other
"mode_param" processing going, which could possibly get the run mode
from PATH_INFO (a current feature).
> I was trying to keep it as close to the existing
> CGI::Application::Dispatch. Since I was only envision a second
> optional param being added it seemed unnecessary to introduce a hash.
> (I've been working with a few modules like XML::Writer lately that
> follow such a convention.)
I can envision other cases where that would work, just like subroutines
that have only two parameters don't name them.
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
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]
