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

[franck]

if you want to know if a request is ajax, you can do request->is_ajax.
Should return true if the request has a XMLHttpRequest header.

On Sat, Dec 25, 2010 at 6:31 AM, Naveed Massjouni <naveedm9 at gmail.com>wrote:

> 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
> >
> ===========================================================================
> >
> _______________________________________________
> Dancer-users mailing list
> Dancer-users at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20110104/c6b41402/attachment-0001.htm>