[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