[Catalyst] Handling arguments with Reges vs the meaning of paths

[apv]

On Friday, January 6, 2006, at 07:24  AM, Matt S Trout wrote:
>> Yes, as far as Catalyst is concerned. A parsed query string becomes 
>> the
>> arguments for standard CGI. And a good standard for URIs is
>> that what appears to be a literal "/this/is/something" should
>> really map to something directly and with full meaning; no matter
>> what is happening in the background (file system, dispatch, 302s, 
>> ...).
>
> Which is why, for example, one might have a URI like
>
>  /<category>/item/<id>
>
> However, in Catalyst you'd do this by registering a Regex of 
> ^/(.*)/item$
> and grabbing the id out the args. If the object/record/whatever 
> corresponding
> to that id doesn't exist, sure, 404 it - but Catalyst's default actions
> explicitly provide longest-match dispatch, and for a majority of 
> situations
> that's incredibly useful.
I probably wouldn't write a regex that way. Dot-star is almost always a
mistake; even when it works it's probably going to be less efficient
than a pattern that won't necessitate backtracking (pretty sure but I'm 
not
a regex guru).

I would also write it to capture the id to snippets b/c you should 
write a
check for it anyway, why not in the Regex().

I do agree that for the majority of intended usage situations it's 
great,
the unintended usage situations, however unlikely, are virtually 
infinite.
So "majority" is contextual.

> Look at the DispatchType system and the way actions are registered; it
> should be easy enough to implement.
Eek. I'll take a stab. It's so much easier to tell other people to do 
it, though,
can't I just keep doing that?  :)
>
>> I'll add that to the wish/fix/discussion list: a "Literal" dispatch
>> type that accepts no path arguments. Would also work as
>> sub index : Literal {} to catch on the local "/."
>
> That's how index already works.
Sorry, I was being a dummy.
>
>>> If $ instead matches the end of the path then someone that wants
>>> arguments cannot as easily get them.  As it is now if you really
>>> don't
>>> want to accept requests with extra PATH_INFO you can just check
>>> $path_args, as in your example above.
>>>
>>
>> If you want more arguments you could easily get them by leaving off 
>> the
>> '$'
>> and signifying the end of your desired string with other regex
>> techniques.
>
> However that would be a substantial backwards-compatibility breakage 
> because
> $ already means something else currently.
Yes. Now is the time though. If Catalyst's features are already locked 
down,
it should probably be announced. :) Slightly painful/irritating changes 
are
possible now for long term sensibility.

The proposition would result in a few hackers changing a few lines of
code today but would let a thousand hackers each avoid writing dozens
of lines of code down the road (assuming they do full argument checking
which is the best practices baseline for my side of the discussion).

As a tangent, I was thinking last night that this sort of fudginess with
argument handling is the kind of thing that a detractor will latch onto.
"Oh, Catalyst? Not only is it written in _Perl_ but they don't even 
check
args let alone type them."

> Read 'sub register_actions' in Catalyst::Base, then look at
> setup_actions and prepare_action in Catalyst::Dispatcher and how the
> Catalyst::DispatchType::* and Catalyst::Action objects interact; I'd
> be very interested to see an implementation of :Literal done this way;
> much of my work on the 5.5 dispatcher was to make the sort of 
> extensions
> you're talking about easy to do.
I really appreciate the pointers. I have not looked at the guts of 
Catalyst
yet. I'll try to dive in this weekend.


-Ashley