Quoting Kadir Beyazlı <[email protected]>:
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¶m2=value¶m3=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...
_______________________________________________
dancer-users mailing list
[email protected]
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
