[dancer-users] Methods Of retrieving request parameters

Kadir Beyazlı kadirbeyazli at gmail.com
Mon Jul 11 11:02:42 BST 2016


Hi Dave,

Thank you very much for clear explanation.
I learnt this wonderful property now.

Best Regards


On Mon, Jul 11, 2016 at 12:29 PM, Dave Cross <dave at dave.org.uk> wrote:
>
> 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...
>
>
>
>
> _______________________________________________
> dancer-users mailing list
> dancer-users at dancer.pm
> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users



-- 
Kadir Beyazlı
Computer Engineer
GSM : +90 535 821 50 00


More information about the dancer-users mailing list