[Dancer-users] Dancer-users Digest, Vol 10, Issue 41
awnstudio at gmail.com
awnstudio at gmail.com
Sat Dec 25 15:17:07 CET 2010
cli request won't have $env{user-agent} and other keys. I did this with sweetpea, you can return the %env oject for cli and browser and compare, then base you logic on that.
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: dancer-users-request at perldancer.org
Sender: dancer-users-bounces at perldancer.org
Date: Sat, 25 Dec 2010 06:03:12
To: <dancer-users at perldancer.org>
Reply-To: dancer-users at perldancer.org
Subject: Dancer-users Digest, Vol 10, Issue 41
Send Dancer-users mailing list submissions to
dancer-users at perldancer.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
or, via email, send a message with subject or body 'help' to
dancer-users-request at perldancer.org
You can reach the person managing the list at
dancer-users-owner at perldancer.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dancer-users digest..."
Today's Topics:
1. one route, different actions based on context (Puneet Kishor)
2. Re: one route, different actions based on context (Puneet Kishor)
3. Re: one route, different actions based on context (Puneet Kishor)
4. Re: one route, different actions based on context
(Alastair Sherringham)
5. Re: one route, different actions based on context (Puneet Kishor)
6. Re: one route, different actions based on context
(Naveed Massjouni)
7. Re: one route, different actions based on context (Puneet Kishor)
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Dec 2010 13:17:09 -0600
From: Puneet Kishor <punk.kish at gmail.com>
Subject: [Dancer-users] one route, different actions based on context
To: dancer-users <dancer-users at perldancer.org>
Message-ID: <4D14F1B5.8060803 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I am fairly certain I saw mention of this in the docs, but I can't find
it now, so here goes --
The route `get '/all'` is invoked from the browser by going to
http://application/foo/all. This causes a template to be rendered with
all the "chrome" of the application, the buttons, the forms, the logos,
bylines, etc. The crap that Edward Tufte refers to as "administrivia."
This template is appropriately filled with data from a query for "all"
foo widgets from the data store.
Well, I also want `get '/all'` to callable from the command line. So, if
the user types
$ curl http://application/foo/all
a json stream of all the foo widgets is returned.
How do I accomplish the above? That is, have a single route called `get
'/all'` and yet be able to call it either from a browser or from a
command line but with different "stuff" returned? Seems like the ajax
plugin is not the solution? or is it? I can't make out from its
documentation.
--
Puneet Kishor
------------------------------
Message: 2
Date: Fri, 24 Dec 2010 13:48:06 -0600
From: Puneet Kishor <punk.kish at gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
context
To: dancer-users <dancer-users at perldancer.org>
Message-ID: <4D14F8F6.5090603 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Adding to my own email...
Puneet Kishor wrote:
> I am fairly certain I saw mention of this in the docs, but I can't find
> it now, so here goes --
>
> The route `get '/all'` is invoked from the browser by going to
> http://application/foo/all. This causes a template to be rendered with
> all the "chrome" of the application, the buttons, the forms, the logos,
> bylines, etc. The crap that Edward Tufte refers to as "administrivia."
> This template is appropriately filled with data from a query for "all"
> foo widgets from the data store.
>
> Well, I also want `get '/all'` to callable from the command line. So, if
> the user types
>
> $ curl http://application/foo/all
>
> a json stream of all the foo widgets is returned.
>
> How do I accomplish the above? That is, have a single route called `get
> '/all'` and yet be able to call it either from a browser or from a
> command line but with different "stuff" returned? Seems like the ajax
> plugin is not the solution? or is it? I can't make out from its
> documentation.
>
>
I guess what I want is to determine where the request is coming from,
perhaps via the headers. If it is an XHR then send only the json stream,
otherwise, send back the template.
--
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
===========================================================================
------------------------------
Message: 3
Date: Fri, 24 Dec 2010 15:35:06 -0600
From: Puneet Kishor <punk.kish at gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
context
To: dancer-users <dancer-users at perldancer.org>
Message-ID: <4D15120A.8080309 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Adding again to my own email...
Puneet Kishor wrote:
> Adding to my own email...
>
> Puneet Kishor wrote:
>> I am fairly certain I saw mention of this in the docs, but I can't find
>> it now, so here goes --
>>
>> The route `get '/all'` is invoked from the browser by going to
>> http://application/foo/all. This causes a template to be rendered with
>> all the "chrome" of the application, the buttons, the forms, the logos,
>> bylines, etc. The crap that Edward Tufte refers to as "administrivia."
>> This template is appropriately filled with data from a query for "all"
>> foo widgets from the data store.
>>
>> Well, I also want `get '/all'` to callable from the command line. So, if
>> the user types
>>
>> $ curl http://application/foo/all
>>
>> a json stream of all the foo widgets is returned.
>>
>> How do I accomplish the above? That is, have a single route called `get
>> '/all'` and yet be able to call it either from a browser or from a
>> command line but with different "stuff" returned? Seems like the ajax
>> plugin is not the solution? or is it? I can't make out from its
>> documentation.
>>
>>
>
>
> I guess what I want is to determine where the request is coming from,
> perhaps via the headers. If it is an XHR then send only the json stream,
> otherwise, send back the template.
>
>
Nope, that is not what I want. 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.
--
Puneet Kishor
------------------------------
Message: 4
Date: Fri, 24 Dec 2010 22:10:54 +0000
From: Alastair Sherringham <sherringham at gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
context
To: dancer-users <dancer-users at perldancer.org>
Message-ID:
<AANLkTi=y1m4kRLqi7uDPZXYt24LdFcwkiuXGFqv0LRnG at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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>
Cheers,
--
Alastair Sherringham
http://www.sherringham.net
------------------------------
Message: 5
Date: Fri, 24 Dec 2010 17:02:51 -0600
From: Puneet Kishor <punk.kish at gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
context
To: Alastair Sherringham <sherringham at gmail.com>
Cc: dancer-users <dancer-users at perldancer.org>
Message-ID: <4D15269B.8060908 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
>
> Cheers,
>
>
--
Puneet Kishor
------------------------------
Message: 6
Date: Fri, 24 Dec 2010 23:30:02 -0500
From: Naveed Massjouni <naveedm9 at gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
context
To: Puneet Kishor <punk.kish at gmail.com>
Cc: dancer-users <dancer-users at perldancer.org>
Message-ID:
<AANLkTi=_BLWb-MgxTdh4_5C0d9MQ0fEzocqMqhmW=5+P at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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
-Naveed
>
>
>
>>
>> Cheers,
>>
>>
>
>
>
> --
> Puneet Kishor
> _______________________________________________
> Dancer-users mailing list
> Dancer-users at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>
------------------------------
Message: 7
Date: Fri, 24 Dec 2010 23:02:59 -0600
From: Puneet Kishor <punk.kish at gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
context
To: Naveed Massjouni <naveedm9 at gmail.com>
Cc: dancer-users <dancer-users at perldancer.org>
Message-ID: <4D157B03.8050800 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
--
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
End of Dancer-users Digest, Vol 10, Issue 41
********************************************
More information about the Dancer-users
mailing list