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 <d...@dave.org.uk> wrote:
>
> Quoting Kadir Beyazlı <kadirbeya...@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¶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
> dancer-users@dancer.pm
> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
--
Kadir Beyazlı
Computer Engineer
GSM : +90 535 821 50 00
_______________________________________________
dancer-users mailing list
dancer-users@dancer.pm
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
