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
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 ===========================================================================
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
On 24 December 2010 19:48, Puneet Kishor <punk.kish@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
Alastair Sherringham wrote:
On 24 December 2010 19:48, Puneet Kishor<punk.kish@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
On Fri, Dec 24, 2010 at 6:02 PM, Puneet Kishor <punk.kish@gmail.com> wrote:
Alastair Sherringham wrote:
On 24 December 2010 19:48, Puneet Kishor<punk.kish@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@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Naveed Massjouni wrote:
On Fri, Dec 24, 2010 at 6:02 PM, Puneet Kishor<punk.kish@gmail.com> wrote:
Alastair Sherringham wrote:
On 24 December 2010 19:48, Puneet Kishor<punk.kish@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 ===========================================================================
On Sat, Dec 25, 2010 at 12:02 AM, Puneet Kishor <punk.kish@gmail.com> wrote:
Naveed Massjouni wrote:
On Fri, Dec 24, 2010 at 6:02 PM, Puneet Kishor<punk.kish@gmail.com> wrote:
Alastair Sherringham wrote:
On 24 December 2010 19:48, Puneet Kishor<punk.kish@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 ===========================================================================
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@gmail.com>wrote:
On Sat, Dec 25, 2010 at 12:02 AM, Puneet Kishor <punk.kish@gmail.com> wrote:
Naveed Massjouni wrote:
On Fri, Dec 24, 2010 at 6:02 PM, Puneet Kishor<punk.kish@gmail.com> wrote:
Alastair Sherringham wrote:
On 24 December 2010 19:48, Puneet Kishor<punk.kish@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@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (4)
-
Alastair Sherringham -
franck -
Naveed Massjouni -
Puneet Kishor