On Date: Mon, 12 Dec 2005 04:37:50 +0000 (UTC), Mark Stosberg <[EMAIL PROTECTED]> wrote: > 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.
REST::Application might be another reference worth checking out http://search.cpan.org/~moconnor/REST-Application-0.01/Application.pm My own homegrown, not-ready-for-general-consumption set-up uses some code pillaged from REST::Application and looks like this to parse path info and set run_mode and named params: $self->param('runmode_map', { qr!^/view/(\d+)! => ["rm_view", "item_id"], qr!^/edit/(\d+)! =>{ GET => ["rm_edit", "item_id"], POST => ["rm_edit_in", "item_id"], }, qr!^/add/?! =>{ GET => ["rm_show_form"], POST => ["rm_add_in"], }, qr!^/search/?! =>{ GET => ["rm_search_form"], POST => ["rm_search_in"], }, qr!^/delete/(\d+)! => ["rm_delete", "item_id"], qr!^/list/csv/?! => "rm_list_csv", qr!^/list/?$! => "rm_list", } ); $self->mode_param( \&set_rm ); Excuse the lack of explanation (no time right now or for the next week or so), but I think it's more or less self-explanatory. This is in my app set-up rather than in dispatch, but I think the basic idea applies. Does this trigger any synapses for anyone? Dave > > >> 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/cgiapp@lists.erlbaum.net/ > http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]