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

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

Dev and Release workflow ( was: Re: Invalid value for log config )
by damien krotkine 20 Dec '10

20 Dec '10

*top-posting* OK here is a first version of my opinion. You may not like it :) I'm playing a bit of devil's advocate too. We are talking about Dancer : a cool project that is very easy to use, to start with, and to build your web platform on. I suggest we try to have the same goal for the development and release environment. So there should be no thinking needed when getting a production release on CPAN, and there should be freedom to hack Dancer code 1/ About CPAN releases : I don't think it's useful to have even and odd releases visible for user (aka on CPAN). Either you have something stable you are happy to ship for production use, and you ship it on CPAN, or you don't ship it at all. Having multiple versions on CPAN with odd numbers, etc, will make it more difficult for users to know which one is good for them. Especially because we don't have strict deadlines. So basically, you may end up in 2014 having 1.4 good and stable since feb 2011 but with an old set of features, and 1.5 containing a bunch of new features, but considered unstable. Basically that's the debian approach (*ouch* don't *ouch* hit me! ), and release management and cycles will become a nightmare. So I'm in favor for 1.2 and 1.3 being both stable versions. And only these to be released on CPAN. 2/ About github : The problems we have currently is that : - the dev manager (sawyer for now I think - congrats) has to choose what to pick up from developers branches. He has to handle conflicts, test failing and so on, if the branch has been made long time ago - the developer is frustrated because he doesn't see his code merged in devel before long ( he's being said "after we release 1.2", "after advent calendar", "after we have talked about it", etc) To fix these issues, I propose that we keep devel and master as we have them, but add a new *experimental* branch. It's a big open sandbox : - this experimental branch is recreated from devel each time a new stable version is done, or when the dev manager thinks it's too messy - Dancer developers are trusted : they can push new branches and *merge* them into experimental, as long as they don't use rebase, and that the test suite passes - the dev manager picks up branches he likes from the experimental branch When new versions are released, the sandbox is cleaned up, experimental branch is wiped out and recreated from devel, and a next cycle can occur. Benefits : - developers can see their work in action in the code. Other dev will get the features immediately, they will react quickly : either they like it, or they don't, so they argue with the developer that merged the change. But they are not frustrated anymore - dev manager has less work to do regarding conflicts and merge issues, because developers take care of test passing when they merge - dev manager has an easy way to clean up things : wipe out experimental and recreate it Because we use git, developers don't loose their work when experimental is wiped out : they have their own branches. All they have to do is to rebase them on the new experimental branch, and fix tests / conflicts if any. This way of doing is from a simplified version of previous work experience. Just my 2 cents, may be useful for the discussion. Remember, developers freedom is important :) On 17 December 2010 11:10, Alexis Sukrieh <sukria(a)sukria.net> wrote: > Le 16/12/2010 20:16, sawyer x a écrit : > > Our deprecation policy is to warn of deprecated behavior in the current >> release version in which it was deprecated (1.2x, 1.3x, whatever), and >> die fatally in a following major release. >> > > Indeed. > > > This could be added in Dancer 1.3x, including the deprecation warning. >> Then removed entirely in 1.4x. >> > > I agree, using the 1.3 releases serie for deprecating stuf inn 1.2 sounds > good. Making them fatal error in 1.4 makes sense. > > This strategy sounds good: release series with even number (1.2, 1.4, 1.6, > ...) always contain stable features, intermediate series can deprecate > things in the previous serie (1.3 can deprecate, with warnings, stuff in > 1.2). > > I like that. > > > 1,2x was released only recently, so I'm not sure if we already want to >> deprecate stuff for the big chunk of users we now added (thanks to many >> marketing efforts by the entire community). >> > > As explained, I'd rather never deprecate anything in a stable serie, 1.2xxx > is meant to provide bugfixes, documentation updates to the 1.2000 release, > only. New features should be added to 1.3xxx in my opinion. And this is > where deprecation can occur. > > So: > > 1.2xxx => stable codebase, no deprecation, no new features > 1.3xxx => development codebase, deprecation, new features > > I welcome your points of view on this strategy. > > This also reminds me we need a new permanent branch on the repo, like > experiemntal, where we will build releases for 1.3 > > I use such a layout at work, and it works pretty well (with git-flow > configured in two different ways): > > 2.0000 > -[ master ]------------------------------|-----------------------> > > -[ devel ]--+----------------------------+----------------------> > \ / > \-[ topic/XXXXX ]--------/ > > > This layout is good for maintaining one release cycle, but if we want to > provide development releases in parallel (1.3xxx) we need one more branch. > Otherwise it will be veru difficult to maintain the 1.2 serie. > > So the layout could become somthing like this: > > > 2.0000 > -[ rel-stable ]-----------------------|-----------------------> > > -[ dev-stable ]--+----------------------------+----------------------> > \ / > \-[ topic/XXXXX ]--------/ > > 2.000 ... 3.0001 > -[ rel-unstable ]-----------------|------------|-----------> > > -[ dev-unstable ]--+----------------------------+----------------------> > \ / > \-[ topic/XXXXX ]--------/ > > > The rel- branches are used by git-flow to produce releases, the dev- ones > are used as integration branches. > > My main concer is how can we publish those releases on CPAN... > > > >> Either way, there's no reason why not to start using this structure >> manually and implement the new strictures in a new branch to be merged >> on whichever release in which we want it. I'll try to get on it sometime >> soon. >> > > Yes, that's another way of doing it, maybe more simple: use some parallel > branches and merge them when we want, but I fear this will become very hard > to maintain over time, if we want 1.2xxx to remain stable. > > Feel free to coment on that idea. > > Regards > > -- > Alexis Sukrieh > > _______________________________________________ > Dancer-users mailing list > Dancer-users(a)perldancer.org > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >

4 7

Getting auto_reload to work
by Deepak Gulati 19 Dec '10

19 Dec '10

Hi Folks, I am trying to get my dancer app to restart/reload any time I change a module in my lib directory. I've set auto_reload to 1 in config.yml and have Module::Refresh and Clone modules installed but nothing seems to happen when I make a change to a module in the lib folder and I have to manually restart for my changes to take effect. I am on Perl 5.10.1 and Dancer 1.2002 running on Mac OS 10.6.5. What am I doing wrong? I realize that auto_reload isn't meant for production use, but it'd be nice to have my changes loaded automatically on my dev box. Thanks, Deepak

8 13

Known problems with Open3?
by ambs 19 Dec '10

19 Dec '10

Hello I am still in debug mode, but does anybody had any problem with open3 when running the standalone server? It seems that STDOUT is getting linked somehow to the terminal window where app.pl is being run. More details as I find them :) Cheers ambs

2 5

dancer websockets tutorial
by Naveed Massjouni 19 Dec '10

19 Dec '10

So I finally got time wrap my head around Franck's chat demo that uses websockets. I was thinking about making a tutorial for creating websocket apps using dancer. And including it in the dancer docs somewhere like lib/Dancer/WebSocketTutorial.pod. Do you guys think this makes sense and would be useful? -Naveed

5 5

Re: [Dancer-users] Known problems with Open3?
by ambs 18 Dec '10

18 Dec '10

On 18/12/2010 20:40, sebastian de castelberg wrote: >>>> I am still in debug mode, but does anybody had any problem with open3 >>>> when running the standalone server? >>>> >>>> It seems that STDOUT is getting linked somehow to the terminal window >>>> where app.pl is being run. >>> >>> For those wanting to help me debug, here is a teste case: >>> >>> http://paste.perldancer.org/1oRJn4LgYzcfV >>> >>> Not sure if this is open3 fault, or Plack/Dancer that is changing >>> something it shouldn't... >> >> Seems an open3 bug: http://rt.perl.org/rt3/Ticket/Display.html?id=66224 > > Save and reset STDOUT is a workaround. > http://paste.perldancer.org/EZUg9A5NVEv5 Hmms, thanks. Now the script is crashing a little ahead with a broken pipe when writing to that filehandle... Let see if I can debug it... Thanks, again :) Alberto

1 0

Deploying with fcgid under a specific directory
by ambs 18 Dec '10

18 Dec '10

Hello I am deploying dancer in a directory, like http://server/query instead the root path. This is my redirect configuration: RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^/query(.*)$ /query/dispatch.fcgi$1 [QSA,L] While the main page works, when I use <% request.base %>file in a template, it gets http://server/queryfile I tried to solve this, using <% request.base %>/file, but then it gets as http://server//file when testing with bin/app.pl What am I doing wrong? Also, when using "redirect /" in Dancer code, should I use "redirect /query" instead? Or "redirect request->{base}" ? Thank you ambs

1 2

Error log with fcgid
by ambs 18 Dec '10

18 Dec '10

Hello Where should I find errors when running Dancer with fcgid? my logs/ log files are all empty :( Thank you ambs

2 1

Selectively calling before() from route handlers
by Gurunandan Bhat 17 Dec '10

17 Dec '10

Hi, Is there a way I can set whether a particular route handler calls before(). I am looking to implement authenticated/unauthenticated routes and would like to execute before() only if the route requires authentication. Any suggestions in doing something like this would be great. Thanks.

3 3