Multiple routes that execute the same action

perl_help26 has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Multiple routes that execute the same action by tobyink (Canon) on Mar 28, 2014 at 10:09 UTC
People using Moose sometimes forget that Moose is still Perl. They need to do something unusual; something outside the bounds of what Moose has sugar for, and they forget that they've still got the rest of Perl at their disposal, and what they want to do is actually pretty easy. Now it seems that Dancer has the same problem. What you want is to do is actually pretty easy. Don't forget you have all of Perl at your disposal, including, (shock!) variables that you can, like, assign stuff to, and then, like, re-use in multiple places... `{ my $code = sub { ... }; my @paths = qw( /myaction1/:param1 /myaction2/:param2 ); get($_, $code) for @paths; }` [download] `use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name`	[reply] [d/l]
Re^2: Multiple routes that execute the same action by McA (Priest) on Mar 28, 2014 at 12:40 UTC
Hi Tobyink, this is a very interesting point. This would mean IMHO that the documentation for a DSL should also show what is done behind the scene and that a DSL construct is "just" syntactic sugar. But often exactly this is not intended because the DSL should hide implementation to force a kind of thinking or working. Or do you think that a "user" should take the time to look what is done with the DSL constructs? Regards McA	[reply]
Re^2: Multiple routes that execute the same action by perl_help26 (Beadle) on Mar 28, 2014 at 13:19 UTC
Thank you that's great!	[reply]
Re: Multiple routes that execute the same action by moritz (Cardinal) on Mar 28, 2014 at 10:28 UTC
Sure. If you want to reuse code, you simply give it a name, and use that name twice. `sub handle_my_request { ... } for my $route ('/myaction1/:param1', '/myaction2/:param2') { get $route, \&handle_my_request; }` [download] Most frameworks also allow you to write the code as methods in a controller class (see for example Mojolicious::Guides::Growing). Perl 6 - the future is here, just unevenly distributed	[reply] [d/l]
Re^2: Multiple routes that execute the same action by perl_help26 (Beadle) on Mar 28, 2014 at 13:21 UTC
the use of the function reference is very neat thanks	[reply]
Re: Multiple routes that execute the same action by zentara (Cardinal) on Mar 28, 2014 at 09:55 UTC
Interesting problem. From the old basic CGI module, you can easily dump all your input parameters into a hash, then you would need to do some logic on the hash keys to send certain inputs to the same subroutine. `my %input= $cgi->Vars(); foreach $name (keys %input){ $value = $input{$name}; } #now test for conditions if ((-e $input{"whatever") && (-e $input{"wherever") ) { your subroutine goes here } # I may have missed some details involving autovification of hash keys +, # and grepping the %input hash keys may be better, but right now, # I'm not sure of the cleverest way to grep an array for 2 values. # I leave that to you, or a more clever monk than me.` [download] I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh	[reply] [d/l]
Re^2: Multiple routes that execute the same action by Anonymous Monk on Mar 28, 2014 at 18:24 UTC
use CGI->param not CGI->Vars , CGI->Vars has caveats	[reply]
Re: Multiple routes that execute the same action by locked_user sundialsvc4 (Abbot) on Mar 28, 2014 at 12:33 UTC
Most of the time, the URL-matching algorithms (in any framework ...) allow you to specify regular-expressions of various sorts to specify the URLs that should invoke a particular subroutine. And, they usually allow for a list of regexes to be associated with any particular `sub`. That being said ... consider also that maybe the simplest and most obvious approach might be the best one: specify different subroutines for each URL pattern, and have each of them gather-up whatever parameters might be in their URLs (each in their own way), and then `return` the result of a call to a separate, common subroutine to handle the common behavior. To my way of thinking, this puts no real burden on the programmer, is perfectly clear, and graciously facilitates variations in the URL-layout without adding complexity or “coupling” one routine to another.