[Catalyst] Handling arguments with Reges vs the meaning of paths
apv
apv at sedition.com
Thu Jan 5 23:18:44 CET 2006
First, to set a baseline, I love Catalyst and am working on 3 different
projects with it.
Now, I am arguing that the Regex argument (not snippet) handling is
conceptually broken and should be changed.
http://host.xyz/this/is/a/path
http://host.xyz/?these=1;are=1;arguments=1
If I have a Regex ('whatever/(STOP-HERE)$'), I really mean the '$'. I
want it to stop.
I don't want to slurp up more path into arguments because it's not
mapping to anything
the application does.
http://host.xyz/whatever/STOP-HERE/meaningless/misleading/nonsense/
should/404
A path is, conceptually, a pointer to a real thing. Not an arbitrary
set of parameters which
may or may not map to results. This is different from query string
arguments which are
conceptually asking a question for which there may be no answer. E.g.:
http://google.com/search?q=%22no+resultz+possible+for+query_string%22
Even in the rare cases where paths can be arbitrary, like
http://answers.com/perl%20catalyst
They are typically limited to 1 argument.
So, I'm in the position where I'm about to start adding:
my ( $self, $c, $path_args ) = @_;
die 404 if $path_args;
into most all my Regex controllers.
The solution, if anyone agrees, is to allow '$', '\Z', '\z' to truly
end what
the Regex controller will accept. If there is more, it should be kicked
down to
the default(s) where several (or all) can be handled at once instead of
per
controller sub.
Yes, sensible? No, crazy talk?
Thanks for looking!
-Ashley
More information about the Catalyst
mailing list