[dancer-users] Methods Of retrieving request parameters

[Dave Cross]

Quoting Kadir Beyazlı <kadirbeyazli at gmail.com>:

> Hi,
>
> At my projects I always used params hash reference to retrieve request
> parameters as follow:
>
> get '/hello/:name' => sub {
>     return "Hi there " . params->{name};
> };
>
> I started reading Dancer ManuaI again to discover new features whether
> I missed and realized that using following ones are safer:
>
> route_parameters->get('name');
> query_parameters->get('name');
>
> There is also param('name') method. As a result I see that there are 4 ways:
>
> get '/hello/:name' => sub {
>     return "Hi there " . params->{name};
>     # or
>     return "Hi there " . route_parameters->get('name');
>     # or
>     return "Hi there " . query_parameters->get('name');
>     # or
>     return "Hi there " . param('name');
>
> };

You missed one. There's also:

   body_parameters->get('name')

> Is there any technical difference between these ways that one of them
> can work at a special case but others don't?

Yes, there's a big technical difference.

There are three places where your app can get parameters from. You can  
get parameters from the query string.

   http://example.com/yourapp?param1=value&param2=value&param3=value

You can also get parameters from Dancer's route matching.

   get '/:param1/:param2/:param3' => sub { ... };

Or you can get parameters from the body of the request (typically from  
a <form> that has been submitted as a POST request.

The three keywords that are now recommended, all force you to say  
explicitly where the parameter can be found - whether it's in the  
query (query_parameter), the route matching (route_parameters) or the  
request body (body_parameters). The keywords which don't specify where  
to find the parameters (param or params) both look in all three places  
for the parameter name.

> If there is no difference except being safer (I got this info from
> manual), is the reason of this diversity to support  Perl motto
> TMTOWTDI?

The more explicitly-named methods are definitely safer. You really  
want to know where your parameters are coming from. These are the  
methods that you should be using.

I assume the older methods are still supported for backwards  
compatibility. I don't know what the project's plans are about  
deprecating and removing them.

> Which ones are you using at your projects?

I try to use the newer, more explicit, methods in new code. But I bet  
there's a good chance that I'm still using the older approach in code  
that I haven't looked at for a couple of years.

Cheers,

Dave...