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]

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

Thank you that's great!

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).

the use of the function reference is very neat thanks

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]

use CGI->param not CGI->Vars , CGI->Vars has caveats

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.