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

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

03 Jan '11

okay cool, I think this reply should be cool...?!

2 1

Re: [Dancer-users] Dancer-users Digest, Vol 11, Issue 2
by awnstudio＠gmail.com 03 Jan '11

03 Jan '11

Your Rewrite is using .cgi instead of .fcgi. Also it doesn't have a DirectoryIndex. Did you know you could do ... <Files "app"> SetHandler cgi-script </Files> Which in effect treats "app" as a file not a folder :) No more need for symlink ln -s ... - Your truely Sent from my Verizon Wireless BlackBerry -----Original Message----- From: dancer-users-request(a)perldancer.org Sender: dancer-users-bounces(a)perldancer.org Date: Sun, 02 Jan 2011 12:00:02 To: <dancer-users(a)perldancer.org> Reply-To: dancer-users(a)perldancer.org Subject: Dancer-users Digest, Vol 11, Issue 2 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: CGI/FCGI deployment & uri_for (Naveed Massjouni) ---------------------------------------------------------------------- Message: 1 Date: Sat, 1 Jan 2011 06:38:50 -0500 From: Naveed Massjouni <naveedm9(a)gmail.com> Subject: Re: [Dancer-users] CGI/FCGI deployment & uri_for To: Robert Olson <bob(a)rdolson.org> Cc: Dancer-users(a)perldancer.org Message-ID: <AANLkTin+b=YygZ=Qw0HbH1cqVRNo+i6+jdzx1k0P00e-(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 28, 2010 at 5:53 PM, Robert Olson <bob(a)rdolson.org> wrote: > 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? A simple thing that I do when deploying a CGI app is using a soft link instead of a rewrite rule: cd /var/www/cgi-bin # your system's cgi-bin may be at a different location ln -s /path/to/myapp/public/dispatch.cgi myapp You need to tell your web server to treat '^/myapp' as a cgi script. Then you can visit http://<domain>/myapp and it will be the root of your app. uri_for("/dog") should then return http://<domain>/myapp/dog I usually deploy as CGI for playing around or for development. When deploying for production, I use FastCGI, and then it is easy to mount your app to '/' or '/whatever'. -Naveed > > Thanks, > --bob > _______________________________________________ > Dancer-users mailing list > Dancer-users(a)perldancer.org > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users > ------------------------------ _______________________________________________ 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 11, Issue 2 *******************************************

2 1

Re: [Dancer-users] Dancer-users Digest, Vol 11, Issue 2
by awnstudio＠gmail.com 03 Jan '11

03 Jan '11

Also, why do you feel the need to make you paths absolute? <a href="dog">click<a/> will work just fine in most any environment. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: dancer-users-request(a)perldancer.org Sender: dancer-users-bounces(a)perldancer.org Date: Sun, 02 Jan 2011 12:00:02 To: <dancer-users(a)perldancer.org> Reply-To: dancer-users(a)perldancer.org Subject: Dancer-users Digest, Vol 11, Issue 2 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: CGI/FCGI deployment & uri_for (Naveed Massjouni) ---------------------------------------------------------------------- Message: 1 Date: Sat, 1 Jan 2011 06:38:50 -0500 From: Naveed Massjouni <naveedm9(a)gmail.com> Subject: Re: [Dancer-users] CGI/FCGI deployment & uri_for To: Robert Olson <bob(a)rdolson.org> Cc: Dancer-users(a)perldancer.org Message-ID: <AANLkTin+b=YygZ=Qw0HbH1cqVRNo+i6+jdzx1k0P00e-(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 28, 2010 at 5:53 PM, Robert Olson <bob(a)rdolson.org> wrote: > 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? A simple thing that I do when deploying a CGI app is using a soft link instead of a rewrite rule: cd /var/www/cgi-bin # your system's cgi-bin may be at a different location ln -s /path/to/myapp/public/dispatch.cgi myapp You need to tell your web server to treat '^/myapp' as a cgi script. Then you can visit http://<domain>/myapp and it will be the root of your app. uri_for("/dog") should then return http://<domain>/myapp/dog I usually deploy as CGI for playing around or for development. When deploying for production, I use FastCGI, and then it is easy to mount your app to '/' or '/whatever'. -Naveed > > Thanks, > --bob > _______________________________________________ > Dancer-users mailing list > Dancer-users(a)perldancer.org > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users > ------------------------------ _______________________________________________ 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 11, Issue 2 *******************************************

2 1

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

sending back an image
by Puneet Kishor 03 Jan '11

03 Jan '11

I think I had asked a variation of this question earlier, but I don't have a clear resolution, so I ask again. I have several folders full of images like so foo/images/ 1.gif 2.gif 3.gif .. bar/images/ 1.gif 2.gif 3.gif .. I want to send a query like so `http://server/foo/1` or `http://server/bar/3` and get back the correct image. So, I have the following route get '/:model/:model_id' => sub { my $model_id = params->{model_id}; my $model = params->{model}; my $dir = '/Users/punkish/Sites/app/public'; my $img = "$model/images/$model_id.gif"; debug("sending '$dir/$img'"); send_file("$dir/$img"); }; I get the following message in my debug log [90645] debug @0.009700> [hit #1] sending '/Users/punkish/Sites/app/public/foo/images/1.gif' in .. But, the browser says, "Firefox can't find the file at http://server/foo/1" What gives? -- 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

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