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/[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]
---------------------------------------------------------------------
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]
