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

Handling file uploads
by Stefan Oberwahrenbrock 25 Mar '11

25 Mar '11

Hello! I have some trouble handling file uploads with my first dancer app. Maybe someone can point me in the right direction: To get hold of an uploaded file sent via PUT, I have set up this route handler: put '/upload/:file' => sub { my $upload = upload( params->{file} ); debug "My Log 1: " . params->{file}; debug "My Log 2: " . ref($upload); }; To test the handler, I feed it with some data sent by "curl": curl --upload-file /srv/mydata.tar.gz http://localhost:3000/upload/ As far as I understand the documentation, $upload should hold a reference to an object of typ Dancer::Request::Upload now. Thus, methods like "filename", "basename", "tempname" etc. should be accessible. The logfile looks quite good - at the beginning: [3432] debug @0.003234> [hit #1] trying to match `/upload/mydata.tar.gz' against /^\/upload\/([^\/]+)$/ in /usr/local/share/perl/5.10.0/Dancer/Route.pm l. 73 [3432] debug @0.003493> [hit #1] My Log 1: mydata.tar.gz in lib/mywebapp.pm l. 26 But the next line indicates, that $upload is not what I expect it to be: [3432] debug @0.003550> [hit #1] My Log 2: in lib/mywebapp.pm l. 27 In addition to that, calling one of methods mentioned above (e. g. "$upload->filename()" ), produces a runtime error: Can't call method filename on an undefined value at... Probably I have not understood the upload() subroutine correctly - any hint is welcome! Thanks, Stefan -- GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

2 2

Invalid value for log config
by Gabor Szabo 22 Feb '11

22 Feb '11

After a misunderstanding in the environments/development.yml I changed the value of "log" to log: "console" which is incorrect (as this value belongs to logger) but I have not seen any complaints about it. Shouldn't DAncer check if the config params are valid? BTW I also tried to add a configuration parameter that does not exists and it was silently disregarded. As it could be the result of a typo or a misunderstanding I think that should be reported as well. Gabor -- Gabor Szabo http://szabgab.com/

6 15

flash implementation
by Иван Бессарабов 12 Jan '11

12 Jan '11

Hi! I've read http://advent.perldancer.org/2010/3 and I have a question. In the blog implementation, described in the article there is so called "flash". There is a global variable where one stores some message that is available after redirect: my $flash; sub set_flash { $flash = shift } sub get_flash { my $msg = $flash; $flash = ""; return $msg } ) post '/add' => sub { # some lines skipped set_flash('New entry posted!'); redirect '/'; }; I think there can be a problem with this thing: if there are a lot of requests to the site some user can see the flash message that was done for some other user. Am I right? I can see several ways of doing the same way but in more safe way: 1. redirect to page with parameter that identifies flash message (have a problem with not pretty urls) 2. store id to flash message in a cookie 3. store flash message in a session Any other ways?

3 3

one route, different actions based on context
by Puneet Kishor 04 Jan '11

04 Jan '11

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

4 8

invalid status code?
by Gabor Szabo 03 Jan '11

03 Jan '11

I just got this error in the browser: "status code needs to be an integer greater than or equal to 100 at /home/gabor/perl5/local/lib/perl5/Try/Tiny.pm line 42" with lots of drill down but I don't see anything that might tell me what did I do wrong? I don't even know what was the status code, if it was not an integer >= 100 ? Running 1.2003 Gabor

4 5

Re: [Dancer-users] Dancer-users Digest, Vol 10, Issue 45
by Al Newkirk & Associates 03 Jan '11

03 Jan '11

i concur On Mon, Dec 27, 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: Dancer::Plugin::REST proposal (Puneet Kishor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 26 Dec 2010 07:43:48 -0600 > From: Puneet Kishor <punk.kish(a)gmail.com> > Subject: Re: [Dancer-users] Dancer::Plugin::REST proposal > To: Naveed Massjouni <naveedm9(a)gmail.com> > Cc: dancer-users <dancer-users(a)perldancer.org> > Message-ID: <4D174694.6050307(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > First, my thanks to Alexis for writing Dancer::Plugin::REST (DPR), and > thanks to Naveed for continually responding to my persistent questions > and now continuing this very important thread. Supporting REST (via DPR) > should be a core objective of Dancer, by making it as easy as pie > (although, personally, I have never found making a pie to be easy -- the > crust in particular requires great skill). REST is the core of linked > data and the semantic web, and these are great technologies and > objectives worthy of support. > > More below. > > Naveed Massjouni wrote: > > 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. > > From what I understand, PUT and POST may be interchangeable, but here > is how it should play out. PUT should be used when the resource name is > known in advance. POST should be used when the resource name is not > known in advance. So, the following scenario -- > > PUT http://server/Puneet-Kishor > > vs. > > POST http://server/{a bunch of data that would create a new resource > whose URI would be 'Puneet-Kishor'} > > The above seems silly because in the latter scenario (the POST) too I > know what the name of the resource is going to be. But, such is not > always the case. For example, in my current scenario, I am allowing > users to do some analysis and then save that analysis with an easy to > remember name. However, there is no guarantee they will always choose a > unique or a meaningful name. The name is just a mnemonic for making it > easy for *a* user to remember what she did, not a guarantee for global > uniqueness (GFGU). The GFGU is promised via an analysis ID created by > the primary key of the data store in which the analyses are stored. > > Additionally, in my scenario the retrieval of the resource is via the > idea such as > > GET http://server/17 > > which gels well with the idea of sending a bunch of data to the server > via a POST, and letting the server generate the ID that will become the > URI for that resource. > > Of course, in the above scenario, POST also corresponds to an update. > > See the definition of POST from > http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html > > <quote> > - Annotation of existing resources; > - Posting a message to a bulletin board, newsgroup, mailing list, > or similar group of articles; > - Providing a block of data, such as the result of submitting a > form, to a data-handling process; > - Extending a database through an append operation. > </quote> > > That last item, "Extending a database through an append operation," > corresponds to my scenario. > > Further down in the same RFC > > <quote> > The fundamental difference between the POST and PUT requests is > reflected in the different meaning of the Request-URI. The URI in a POST > request identifies the resource that will handle the enclosed entity. > That resource might be a data-accepting process, a gateway to some other > protocol, or a separate entity that accepts annotations. In contrast, > the URI in a PUT request identifies the entity enclosed with the request > -- the user agent knows what URI is intended and the server MUST NOT > attempt to apply the request to some other resource. If the server > desires that the request be applied to a different URI, it MUST send a > 301 (Moved Permanently) response; the user agent MAY then make its own > decision regarding whether or not to redirect the request. > </quote> > > And, finally, "The methods GET, HEAD, PUT and DELETE" should be > idempotent. This means that repeated applications of these methods > should result in exactly the same effect on the store as a single > application. Obviously, POST doesn't belong in this list because > repeated applications of POST (an update) does modify the store > differently each time. > > I believe Dancer should follow RFC 2616 Section 9 to the t in order to > be a good semantic web citizen. > > > 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. > > > I like your ideas very much. I like the mapping of "resource" to a > package that in turn implements the methods, and that throws an > exception of all 4 verbs are not supported, but also allows a manual > override. Mapping to a package will allow me to cleanly build interfaces > for my different kinds of data, allowing me to separate the treatment > for each kind of data in its own package. > > However, most important, by following RFC 2616-9, your proposed > direction would make my application really useful, predictable, and in > conformance with the expectations of the world of linked data. > > Dancer is truly a wonderful framework. In the beginning its new and easy > style for building a web application excited me. Now I am realizing a > new purpose for Dancer. Even though I am putting a lot of work in my web > application, suddenly I care less about that application than in the > access to the data. Suddenly the user of the application is less > important than the user of the data. In fact, my application itself has > become an user of my data. > > Thought carefully through, Dancer can really make very important > contributions to the world of semantic web and linked data by allowing > Perl practitioners build useful data access applications that follow the > recommended, modern principles. > > > > > Regards, > > Naveed > > _______________________________________________ > > Dancer-users mailing list > > Dancer-users(a)perldancer.org > > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users > > > > -- > 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 45 > ******************************************** >

2 1

new site?
by Puneet Kishor 03 Jan '11

03 Jan '11

Dear Ann Landers, Now that Dancer 1.2 is out, when is that beautiful, beautiful new site going to be launched? -- waiting anxiously

4 4

CGI/FCGI deployment & uri_for
by Robert Olson 01 Jan '11

01 Jan '11

It seems I must be doing something dumb, but I'm not seeing it. I'm putting up a dancer app for a domain hosted at dreamhost. I created the app using the latest 1.2 dancer, and changed the webroot for the domain to appdir/public using the DH config panel. The following .htaccess is in place: AddHandler fastcgi-script .fcgi Options +FollowSymLinks +ExecCGI RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule (.*) /dispatch.cgi/$1 [QSA,L] Access to the routes works like a champ (including Net::Google::FederatedLogin authentication which I may turn into a plugin; also thinking about a CGI::FormBuilder plugin like Catalyst's). However, uri_for returns a path that includes the rewritten path with dispatch.cgi in it: uri_for("/dog") => http://<domain>/dispatch.cgi/dog I'm assuming it should instead return http://<domain>/dog. This seems like something there is an easy solution to, but I'm not finding it. Does anyone have any advice? Thanks, --bob

2 2

Accessing template variables inside Wrapper (layout)
by Deepak Gulati 31 Dec '10

31 Dec '10

Hi Folks, Template toolkit allows me to set variables inside a template and then access them from the wrapper: http://www.template-toolkit.org/docs/manual/Config.html#section_WRAPPER This doesn't seem to when using Template Toolkit with Dancer. e.g. in the index.tt that dancer generates, I added: <% foo = "bar" %> on the first line and tried to access it from main.tt <title><% foo %></title> But it comes out as blank. Is dancer doing something special with the wrapper or am I doing something wrong? Thanks, Deepak

3 6

Questions for Perl Survey
by Gabor Szabo 31 Dec '10

31 Dec '10

Hi, I am preparing a survey of the Perl Ecosystem to be run in the beginning of 2011. The survey will build on the questions of the TPF survey from the beginning of the year but I'd like to extend it to understand more issues. Specifically I'd like to figure out how many people are using web development frameworks, which ones they use and what they think about them? So far I have one simple question: What frameworks do you use for web application development? Answers: - I don't develop web applications - plain old CGI - CGI::Applications / Titanium - Dancer - Mojolicious - Catalyst I wonder what other values do you think I should add and what other questions should I ask? It would be especially interesting to try to figure out what people outside of the Perl community think about the various Perl frameworks compared to other frameworks they might know but I have no idea how to ask that. Your input would be appreciated. regards Gabor -- Gabor Szabo http://szabgab.com/ Perl Ecosystem Group http://perl-ecosystem.org/

5 8