[Dancer-users] one route, different actions based on context

[Naveed Massjouni]

On Sat, Dec 25, 2010 at 12:02 AM, Puneet Kishor <punk.kish at gmail.com> wrote:
>
>
> Naveed Massjouni wrote:
>>
>> On Fri, Dec 24, 2010 at 6:02 PM, Puneet Kishor<punk.kish at gmail.com>
>>  wrote:
>>>
>>> Alastair Sherringham wrote:
>>>>
>>>> On 24 December 2010 19:48, Puneet Kishor<punk.kish at gmail.com>    wrote:
>>>>>>
>>>>>> $ curl http://application/foo/all
>>>>>>
>>>>>> a json stream of all the foo widgets is returned.
>>>>
>>>> There's an advent calendar up just now with some advice on this sort
>>>> of thing e.g.
>>>>
>>>> Writing REST web services with Dancer
>>>> http://advent.perldancer.org/2010/8
>>>>
>>>> Some curl usage - maybe use "application/json"? e.g.
>>>>
>>>> curl -H 'Accept-Type: application/json'<url>
>>>
>>> Thanks. A great article, helps clear the fog further.
>>>
>>> Nevertheless, my problem now is as I articulated in my last email. What I
>>> want is to send back the template only if being request via a browser as
>>> a
>>> regular, non-Ajax request  (how should I determine that?). Otherwise, if
>>> it
>>> is being called via Ajax or from the command line via curl or lwp or
>>> whatever, a json stream should be returned. So, given (pseudocode ahead)
>>> --
>>>
>>>  1 prepare_serializer_for_format;
>>>  2
>>>  3 get '/all.:format' =>  sub {
>>>  4
>>>  5      my $res = query->db->for->all;
>>>  6
>>>  7      # Requested a full web page from the browser, so
>>>  8      # use the template; no need to use a serializer
>>>  9      if (request->came_from_browser_non_ajax) {
>>> 10              template 'all.tt', {res =>  $res, other =>  $options};
>>> 11      }
>>> 12
>>> 13      # For ajax requests or requests from command line,
>>> 14      # use the requested serializer and return a text
>>> 15      # stream
>>> 16      else {
>>> 17              return to_json $res;
>>> 18      }
>>> 19
>>> 20 };
>>>
>>> The idea is that a user can go to http://server/foo/all and see the
>>> entire
>>> web page as rendered by the template 'all.tt', or the user can request a
>>> specific serialized format via the command line and get a text stream
>>> back.
>>> Would be nice to have a default serialization format defined, so, for
>>> example, if no specific format is requested then JSON can be sent back,
>>> else, XML or whatever can be sent back.
>>
>> I haven't tested this, but I think this is all you need:
>>
>> prepare_serializer_for_format;
>> get '/all' { template 'all' };
>> get '/all.:format' =>  sub { return { foo =>  'bar' } };
>>
>> In your javascript ajax call, you would explicitly request /all.json.
>> Same with curl:
>>     curl http://localhost:3000/all.json
>>
>
>
> Thanks Naveed. Yes, it is easy to do that if I declare different routes
> (after all '/all' is different from 'all.:format'). I am wondering if it is
> possible to do it with exactly the same route, thereby creating a consistent
> interface that is also intuitive.

IMO, I think that interface is consistent and intuitive.  End users of
your app will not know if you used 1 route or 2 in your
implementation.  Of course you could do this with just one get('/all')
route.  Then your code will be more complex.  You would then need 'if'
clauses that check headers such as 'Accept', 'User-Agent' and
'X-Requested-With' to determine if it was an ajax request, if they
used curl, if they want json back, etc.  You will be reinventing
wheels as they say.
-Naveed

>
>
>
>
>
> --
> Puneet Kishor http://punkish.org
> Carbon Model http://carbonmodel.org
> Charter Member, Open Source Geospatial Foundation http://www.osgeo.org
> Science Fellow http://creativecommons.org/about/people/fellows#puneetkishor
> Nelson Institute, UW-Madison http://www.nelson.wisc.edu
> ---------------------------------------------------------------------------
> Assertions are politics; backing up assertions with evidence is science
> ===========================================================================
>