Re: [Dancer-users] Dancer-users Digest, Vol 10, Issue 41

25 Dec 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@perldancer.org
Sender: dancer-users-bounces@perldancer.org
Date: Sat, 25 Dec 2010 06:03:12 
To: <dancer-users@perldancer.org>
Reply-To: dancer-users@perldancer.org
Subject: Dancer-users Digest, Vol 10, Issue 41

Send Dancer-users mailing list submissions to
	dancer-users@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@perldancer.org

You can reach the person managing the list at
	dancer-users-owner@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@gmail.com>
Subject: [Dancer-users] one route, different actions based on context
To: dancer-users <dancer-users@perldancer.org>
Message-ID: <4D14F1B5.8060803@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@gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
	context
To: dancer-users <dancer-users@perldancer.org>
Message-ID: <4D14F8F6.5090603@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@gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
	context
To: dancer-users <dancer-users@perldancer.org>
Message-ID: <4D15120A.8080309@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@gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
	context
To: dancer-users <dancer-users@perldancer.org>
Message-ID:
	<AANLkTi=y1m4kRLqi7uDPZXYt24LdFcwkiuXGFqv0LRnG@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

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

------------------------------

Message: 5
Date: Fri, 24 Dec 2010 17:02:51 -0600
From: Puneet Kishor <punk.kish@gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
	context
To: Alastair Sherringham <sherringham@gmail.com>
Cc: dancer-users <dancer-users@perldancer.org>
Message-ID: <4D15269B.8060908@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@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@gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
	context
To: Puneet Kishor <punk.kish@gmail.com>
Cc: dancer-users <dancer-users@perldancer.org>
Message-ID:
	<AANLkTi=_BLWb-MgxTdh4_5C0d9MQ0fEzocqMqhmW=5+P@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

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
------------------------------

Message: 7
Date: Fri, 24 Dec 2010 23:02:59 -0600
From: Puneet Kishor <punk.kish@gmail.com>
Subject: Re: [Dancer-users] one route, different actions based on
	context
To: Naveed Massjouni <naveedm9@gmail.com>
Cc: dancer-users <dancer-users@perldancer.org>
Message-ID: <4D157B03.8050800@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@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
===========================================================================

------------------------------

_______________________________________________
Dancer-users mailing list
Dancer-users@perldancer.org
http://www.backup-manager.org/cgi-bin/listinfo/dancer-users

End of Dancer-users Digest, Vol 10, Issue 41
********************************************

awnstudio＠gmail.com

tags

participants (1)