December 2010 - dancer-users - lists.preshweb.co.uk

Re: [Dancer-users] Dancer-users Digest, Vol 10, Issue 50
by Al Newkirk & Associates 30 Dec '10

30 Dec '10

Naveed, I've used both and my take is ... Since Catalyst is meant to be used for large web apps, the scaffolding tool builds a better foundation with good emphasis on MVC, how you should the components and where to place them. Since the latest runs on Plack as does most everything else, there is no real performance difference. In-Short .. the MVC-ness of Catalyst is the only benefit I can think of. I hate when people throw the term "scale" or "web-scale" around ... WTF does that mean? ... its vague enough that it could refer to any number of factors. Most good object-oriented code will "scale" as that its purpose .. other factors such as platform, database, web server, etc (and their respective scalability) have nothing to do with the frameworks scalability. On Thu, Dec 30, 2010 at 6:00 AM, <dancer-users-request(a)perldancer.org>wrote: > Send Dancer-users mailing list submissions to > dancer-users(a)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(a)perldancer.org > > You can reach the person managing the list at > dancer-users-owner(a)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. Re: Questions for Perl Survey (Olaf Alders) > 2. Re: Questions for Perl Survey (sawyer x) > 3. Catalyst vs Dancer (Naveed Massjouni) > 4. Re: Catalyst vs Dancer (Puneet Kishor) > 5. Re: CGI/FCGI deployment & uri_for (Robert Olson) > 6. flash implementation (???? ??????????) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 29 Dec 2010 11:49:53 -0500 > From: Olaf Alders <olaf(a)wundersolutions.com> > Subject: Re: [Dancer-users] Questions for Perl Survey > To: sawyer x <xsawyerx(a)gmail.com> > Cc: dancer-users(a)perldancer.org > Message-ID: <5F44E6BE-896E-4D31-9AB4-4CF8275C06D7(a)wundersolutions.com> > Content-Type: text/plain; charset=us-ascii > > > On 2010-12-29, at 5:48 AM, sawyer x wrote: > > > Dancer provides a thin layer above PSGI and abstraction for some of the > work a user would have to do manually (sessions, templating, finding out > what type of HTTP method it is, setting the content type, etc.). You (or > rather, Dancer, if that's what you're using) provide PSGI with an app > handler subroutine. For example: > > sub app { > > my $env = shift; > > return [ > > '200', > > [ 'Content-Type' => 'text/plain' ], > > [ "Hello World" ], # or IO::Handle-like object > > > > > > ]; > > > > } > > How many people would do that? Very few. > > True! However, I'd be interested in seeing how many people are writing > their own Plack::Middleware components. As it's a nice and easy way to > replace a lot of work you normally might be forced to write with mod_perl > handlers, I would expect that the use of custom Middleware should rise over > time as well. > > Olaf > -- > Olaf Alders > olaf(a)wundersolutions.com > > http://www.wundersolutions.com > http://twitter.com/wundercounter > > 866 503 2204 (Toll free - North America) > 416 944 8306 (direct) > > > > ------------------------------ > > Message: 2 > Date: Thu, 30 Dec 2010 00:44:44 +0200 > From: sawyer x <xsawyerx(a)gmail.com> > Subject: Re: [Dancer-users] Questions for Perl Survey > To: Olaf Alders <olaf(a)wundersolutions.com> > Cc: dancer-users(a)perldancer.org > Message-ID: > <AANLkTime+W5EmthCa6HoS5L47UZF9w_O2AAKrjUzORp6(a)mail.gmail.com<AANLkTime%2BW5EmthCa6HoS5L47UZF9w_O2AAKrjUzORp6(a)mail.gmail.com> > > > Content-Type: text/plain; charset="iso-8859-1" > > On Wed, Dec 29, 2010 at 6:49 PM, Olaf Alders <olaf(a)wundersolutions.com > >wrote: > > > > > [...] I'd be interested in seeing how many people are writing their own > > Plack::Middleware components. > > > > Good idea! > > > > I would expect that the use of custom Middleware should rise over time > as > > well. > > > > That would be an interesting/useful metric. >

2 1

Catalyst vs Dancer
by Naveed Massjouni 29 Dec '10

29 Dec '10

I have a question for all you Dancer users. When would you use Catalyst over Dancer? Does it "scale" better for larger applications, and if so how/why? I was never able to wrap my head around Catalyst. But it's been a while and I was a perl beginner back when I tried. Now Dancer is my go-to framework for any project. Just wondering if I am missing out on anything. Thanks, Naveed

2 1

limit file upload
by Иван Бессарабов 29 Dec '10

29 Dec '10

Hi! I'm using my "$file = upload('file');" and it works fine, but I don't get it how to limit the size of the uploaded file. Can you please point me to the correct directen? Thank you.

1 0

storing JSON in a db for later use
by Puneet Kishor 28 Dec '10

28 Dec '10

Actually, I had pursued this problem a while back on this list, received helpful suggestions, implemented a solution, and all was working. Except, recently (a few days ago) when it stopped working. I can't quite pinpoint what caused the program to break, but I am now writing to elicit suggestions afresh so I can create a robust solution. I am deploying all the nice touches that Dancer offers, namely, use Dancer::Serializer::Mutable; use Dancer::Plugin::REST; prepare_serializer_for_format; I have a longish JSON object in the browser that I stringify and send back to the server with the help of jQuery. I store this string into a sqlite db. The string looks like [{"data":"{"year":"1900","harvest_area":"126800.00", .. (very long string) At a later time, I retrieve the above value, send it back to the browser where it is reconstructed back into a JSON object which can be used. Except, ever since I started using the automatic serializer, the darn thing has stopped working. The JSON object is not fully reconstructed. The above string is received by the browser as [{"data":"{\"year\":\"1900\",\"harvest_area\":\"126800.00\", .. (very long string) The automatically generated headers received are Request Header -------------- Accept:application/json, text/javascript, */*; q=0.01 Response Header -------------- Content-Type:text/xml; charset=UTF-8 I think it is those escaped double quotes in the response (\"year\") are creating trouble for me. The value of the "data" key in the JSON object should be another dataset, but comes off as a string instead. As I said above, this was working when I didn't use the automatic serializers (D::S::Mutable and D::P::REST with `prepare_serializer_for_format`). I used to retrieve the values from the db, transform them with from_json() to a Perl data structure, created a data structure to return, convert it to a string with to_json() and send it back to the browser. $sth = __PACKAGE__->SUPER::db()->prepare(qq{ SELECT id, name, data, poly FROM foo }); $sth->execute; my @str = (); while (my ($id, $name, $data, $poly) = $sth->fetchrow_array) { push @str, { id => $id, name => $name, data => from_json($data), poly => from_json($poly) } } return to_json(\@str); Now I don't use the from_json() and the to_json() calls. Needless to say, if I use those calls, I get an error on the server side that {"error":"malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before \"(end of string)\") at (eval 64) line 163.\n"} and, if I don't use from_json() and to_json(), I get [{"data":"{\"year\":\"1900\",\"harvest_area\":\"126800.00\", .. which stops my application on the browser side. So, I am stuck. If the above is too confusing, I ask this simple question -- How do I reliably send a stringified JSON object to Dancer (I use the canonical json2.js from Crockford's site), store it in a sqlite table, retrieve it, have Dancer stringify it, send it back to the browser, and reconstruct the original JSON object 100%? I want round-trip browser to db back to the browser. Suggestions? -- 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 ===========================================================================

3 2

request and response headers don't match
by Puneet Kishor 27 Dec '10

27 Dec '10

I am using DP:REST, DS:Mutable, and prepare_serializer_for_format(). I am querying for a JSON response via jQuery like so $.ajax({ url : .., type : "POST", data : "poly=" + JSON.stringify(coords_pix), dataType: "json", error : function() { alert("Error loading html document"); }, success : function(data) { .. do stuff with data .. } }); This is what I seen in Firebug Request Headers =============== .. Accept application/json, text/javascript, */*; q=0.01 .. Content-Type application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With XMLHttpRequest Response Headers ================ Date Mon, 27 Dec 2010 13:23:35 GMT Server Apache/2.2.16 (Unix) DAV/2 mod_perl/2.0.4 Perl/v5.12.1 X-Powered-By Perl Dancer 1.2003 Content-Type text/xml; charset=UTF-8 .. Gak! what happened there? Why did I get back xml even though I requested json? (Note: It is possible that I don't understand accept and response headers at all, in which case, kindly educate me). As a result, Firebug show the JSON output correctly, but complains about the XML output XML Parsing Error: not well-formed Location: moz-nullprincipal:{5063a87c-f476-8346-8452-ab404f4c1282} Line Number 1, Column 1: {"harvest_amt":"14188.62","harvest_area":"126100.00","nep":"404789.50"} ^ -- 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 ===========================================================================

1 0

Dancer::Plugin::REST proposal
by Naveed Massjouni 26 Dec '10

26 Dec '10

DISCLAIMER: I know this is the mailing list for Dancer, but I am writing about a particular plugin. I think it is relevant because it is a pretty important plugin and also because I would like to hear everyone's opinion. Especially Sukria, since it's his plugin. There has been several REST related posts recently and it has reminded me of something that has been bugging me about the Dancer::Plugin::REST module. It provides the keyword resource which works as follows: resource user => get => sub { # return user where id = params->{id} }, create => sub { # create a new user with params->{user} }, delete => sub { # delete user where id = params->{id} }, update => sub { # update user with params->{user} }; But a PUT/POST in REST does not always correspond to UPDATE/CREATE. One of my favorite articles on this topic is: http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/ It's worth reading even if you don't agree with it in the end. It will at least show you a different perspective. Also, his argument is backed up by the HTTP spec. He argues that a PUT can be used to update or create a resource, and the same for a POST. So I have some proposals that could make everyone happy, hopefully. Even if you are happy with the existing CRUD mapping. I think the REST plugin should also support mappings from a resource to http verbs, in addition to the way it works now. For example: resource user => get => sub { # return user where id = params->{id} }, create => sub { # create a new user with params->{user} }, delete => sub { # delete user where id = params->{id} }, update => sub { # update user with params->{user} }, # and also post => sub { }, put => sub { }; Even better is if it supported a dispatch table style: resource user => { get => sub { }, delete => sub { }, post => sub { }, put => sub { }, }; Notice that the second argument to 'resource' is a hashref in the above example. Another cool thing it could support is: resource user => 'User'; Where 'User' is a package/class that could be defined in User.pm: package User; sub get { ... } sub delete { ... } sub post { ... } sub put { ... } 1; Another thing that could be improved is that the 'resource' function throws an exception if the user did not provide mappings for all 4 operations/verbs. But there is no requirement that a resource should support all http verbs. The 'resource' function could provide routes which return a status of 405 Method Not Allowed, for the missing verbs. Do you guys like any of these ideas? Should these ideas be incorporated into the existing REST plugin or a new plugin? I would be glad to implement them, but I wanted to make sure my changes would be accepted before doing the work. Regards, Naveed

2 1

Re: [Dancer-users] Dancer-users Digest, Vol 10, Issue 41
by awnstudio＠gmail.com 25 Dec '10

25 Dec '10

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(a)perldancer.org Sender: dancer-users-bounces(a)perldancer.org Date: Sat, 25 Dec 2010 06:03:12 To: <dancer-users(a)perldancer.org> Reply-To: dancer-users(a)perldancer.org Subject: Dancer-users Digest, Vol 10, Issue 41 Send Dancer-users mailing list submissions to dancer-users(a)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(a)perldancer.org You can reach the person managing the list at dancer-users-owner(a)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(a)gmail.com> Subject: [Dancer-users] one route, different actions based on context To: dancer-users <dancer-users(a)perldancer.org> Message-ID: <4D14F1B5.8060803(a)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(a)gmail.com> Subject: Re: [Dancer-users] one route, different actions based on context To: dancer-users <dancer-users(a)perldancer.org> Message-ID: <4D14F8F6.5090603(a)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(a)gmail.com> Subject: Re: [Dancer-users] one route, different actions based on context To: dancer-users <dancer-users(a)perldancer.org> Message-ID: <4D15120A.8080309(a)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(a)gmail.com> Subject: Re: [Dancer-users] one route, different actions based on context To: dancer-users <dancer-users(a)perldancer.org> Message-ID: <AANLkTi=y1m4kRLqi7uDPZXYt24LdFcwkiuXGFqv0LRnG(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 24 December 2010 19:48, Puneet Kishor <punk.kish(a)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(a)gmail.com> Subject: Re: [Dancer-users] one route, different actions based on context To: Alastair Sherringham <sherringham(a)gmail.com> Cc: dancer-users <dancer-users(a)perldancer.org> Message-ID: <4D15269B.8060908(a)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(a)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(a)gmail.com> Subject: Re: [Dancer-users] one route, different actions based on context To: Puneet Kishor <punk.kish(a)gmail.com> Cc: dancer-users <dancer-users(a)perldancer.org> Message-ID: <AANLkTi=_BLWb-MgxTdh4_5C0d9MQ0fEzocqMqhmW=5+P(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 24, 2010 at 6:02 PM, Puneet Kishor <punk.kish(a)gmail.com> wrote: > > > Alastair Sherringham wrote: >> >> On 24 December 2010 19:48, Puneet Kishor<punk.kish(a)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(a)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(a)gmail.com> Subject: Re: [Dancer-users] one route, different actions based on context To: Naveed Massjouni <naveedm9(a)gmail.com> Cc: dancer-users <dancer-users(a)perldancer.org> Message-ID: <4D157B03.8050800(a)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(a)gmail.com> wrote: >> >> Alastair Sherringham wrote: >>> On 24 December 2010 19:48, Puneet Kishor<punk.kish(a)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(a)perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users End of Dancer-users Digest, Vol 10, Issue 41 ********************************************

1 0

separating code into packages
by Gabor Szabo 25 Dec '10

25 Dec '10

I have not reached that point yet but as your application grows it might be better to move some code and with that some route definition to separate files. For example if I have a Dancer application called Foo I might want to move all the user related methods get '/user/this' => sub { ... }; get '/user/that' => sub { ... }; get '/user/other' => sub { ... }; to a package called Foo::User; I can then include use Foo::User; in the main Foo package and the above routes are added. Within Foo::User the /user prefix seems to be too repetitive so it might be better to have just get '/this' => sub { ... }; get '/that' => sub { ... }; get '/other' => sub { ... }; and mount that package to '/user' within the Foo application. (which by itself might have been mounted to some path. If I understood it correctly from http://advent.perldancer.org/2010/2 and from the recent presentation of Sawyer, this would be getting similar to what MVC frameworks do and what you referred to as "Namespace matching". As I was playing with this idea I implemented a small example I call Dancer::Plugin::MVC for now that would do this automatically. You just include use Dancer::Plugin::MVC; in the main Foo package and during its import() call it will load all the modules in the subdirectories of Foo. So far it simply loads the modules it finds which is quite simple. I'll try to check if I can mount the various modules in other places as well though in that case I might not want to do it for all the modules and the mount point should be the same as the package name. What do you think? Is this totally contradicting the philosophy of Dancer? Gabor

3 5

Dancer with latest Plack and fcgid+apache2
by ambs 25 Dec '10

25 Dec '10

Hello With latest upgrade of Plack, my Dancer app is no longer working. My environment: apache2 + fcgid, configured with: RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^/query(.*)$ /query/dispatch.fcgi$1 [L] This was working, but now, it doesn't. Until now, I had in my Dancer app a rule 'get "/"', and it worked. Now, it seems that Plack is changing the environment for Dancer, and to make the Dancer app to work, I need to have a rule 'get "/query" that I do not want to have (will break devel with standalone server). Also, it is not versatile to move apps between different server configurations. You can check the environment that is getting to Dancer here: http://per-fide.di.uminho.pt/query I think that "PATH_INFO" should not include '/query', but I am not sure. Also, I think this is a plack problem, but I am not sure, and would like your confirmation before complaining there. Cheers And Have a great Christmas! ambs

2 1

RESTful applications in Dancer
by Gabor Szabo 25 Dec '10

25 Dec '10

hi, I have a general web related question and then I wonder which of the answers can be easily implemented in Dancer? I am building an application that probably will be mostly just send out serialized data though I am not 100% sure so I might want to mix in sending out traditional HTML files as well. So I wonder what is the "best practice" to write RES-ish application, one that might also serve HTML? I thought about a few strategies I am going to describe now using a single route as an example: 1) /login always returns HTML no XML, JSON, YAML interface old school, no buzzwords here :) 2) /login always returns HTML /login.yml returns YAML /login.json returns JSON etc. (some of these might be allowed some might not) Q: What is the relationship between the HTML and the YAML? Is the data returned as YAML the same as would be passed to the template for generating HTML? How? 3) /login returns HTML or YAML or JSON depending on the Accept header of the request. In order to fetch the YAML response the request needs to supply: Accept: application/json I am not sure if HTTP allows multiple Accept headers and if yes then how should the application behave? Otherwise the same as 2 above. 4) No HTML responses at all (only some static pages) so 4.2) the serialization is the same as in 2) based on extension 4.3) the serialization is the same as in 3) based on Accept header Are any of these good strategies? Are there other good ones? Which one can be implemented in Dancer and how? regards Gabor -- Gabor Szabo http://szabgab.com/

3 4