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

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

a Dance for the REST of us
by Puneet Kishor 24 Dec '10

24 Dec '10

I have widgets called "foo," and I am building web app that will also serve as a RESTful app for data access via the command line. All "foo" related routes are packaged together, and are loaded via `load_app "app::foo", prefix => "/foo"` so that `get '/:foo_id'` really become `http://server/foo/:foo_id`. My routes are 1. get '/' =========== Returns a welcome page via a full html request. A full html request is where a full web page is loaded, as opposed to an ajax request where only a part of the web page is refreshed. 2. get '/all' ============== Returns minimal info for all valid "foo" from the data store via a full html request. However, I would also like to return them as a json string via the command line. Now, when requested via the web browser, this method should really return only some minimal info for each "foo." Clicking on any specific "foo" should fire #3 below to get its details -- a typical drill-down application. However, when requested via the commandline, there should be an option to return *all* the details, with some checks, so that gigabytes of data are not returned. 3. get '/:foo_id' ================== Returns all the details for a specific "foo" as a json string via an ajax request. 4. get '/new' ============== Returns a page to begin constructing a new "foo" in the browser via a full html request. There is no equivalent command line method for this. 5. post '/save' ======================= Saves a new "foo" created in #4 or above, or via a command line method. In other words, a user should be able to supply in a json string via the command line everything that a user would create interactively in #4 above. 6. get '/delete/:foo_id' ========================= This method removed a specific foo. Now, two things I don't understand about this -- one, of course, in a RESTful app, this would be a DELETE method. This is a bit confusing to me -- is the HTTP get (I am using a lowercase 'get') not the same as a REST GET (using an uppercase get)? In other words, can I use a `get` to perform a `DELETE`? Two, how do I send authentication? I don't want Sukrieh deleting Sawyer's widget. In fact, this authentication theme runs through all the routes -- do I just pass a session token for authentication with every route? Finally, should #3 be the last route? Else, how do I differentiate between `get '/delete/5'` and `get '/5'` and `get '/all'`? Thanks in advance for a quick lesson, whosoever cares to give one. -- Puneet Kishor

2 3

activate cache based on memory usage
by Maurice Mengel 23 Dec '10

23 Dec '10

Dear Dancers, i would like to activate my caching mechanism if perl uses more than a certain amount of memory. Two questions 1) is this the right approach or should I look for some other criterion to active cache? 2) How to do it? I looked at - http://perldoc.perl.org/perldebguts.html#Debugging-Perl-memory-usage and - Memory::Usage, but this seems not to work from under Dancer. Thanks! Maurice

2 2