Simple Dancer OO approach.
Simple Dancer OO approach. The idea is simple -- we need to defer route handler declaration. It could be done with re-definition Dancer DSL words like get, post, any, etc. It's done in Dancer::OO::Dancer module. Deferred declarations are stored in package _handler array variable. This approach allows to define and use common handlers and to write extendable modules that could be mounted to later declared uris. To use this deferred technique package must be inherited from Dancer::OO::Object package, which sole purpose is to install deffered handlers. It does so by building inheritnance tree and calling Dancer::* methods with obvious alterations. Handlers are installed to prefixed routes, thus limiting the route syntax to simple strings. I've included a sample Sample application, which has common Sample::Base for Sample::Root and Sample::Demo packages. https://github.com/jamhed/Dancer-OO -- With best regards, Roman Galeev
This seems like a well thought-out idea, but unfortunately I think it shouldn't be done. Dancer 2 is already completely OO and so is the DSL. The idea now is to simply keep Dancer 1 maintained as far as to let Dancer 2 be developed continually. Once Dancer 2 is ready, we'll start moving to it. It will already contain all the things people suggest to put into Dancer 1, being done more cleanly and correctly. 2012/1/26 Роман Галеев <ip@ncom-ufa.ru>
Simple Dancer OO approach.
The idea is simple -- we need to defer route handler declaration. It could be done with re-definition Dancer DSL words like get, post, any, etc. It's done in Dancer::OO::Dancer module.
Deferred declarations are stored in package _handler array variable.
This approach allows to define and use common handlers and to write extendable modules that could be mounted to later declared uris.
To use this deferred technique package must be inherited from Dancer::OO::Object package, which sole purpose is to install deffered handlers. It does so by building inheritnance tree and calling Dancer::* methods with obvious alterations.
Handlers are installed to prefixed routes, thus limiting the route syntax to simple strings.
I've included a sample Sample application, which has common Sample::Base for Sample::Root and Sample::Demo packages.
https://github.com/jamhed/Dancer-OO
-- With best regards, Roman Galeev _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
На Thu, 26 Jan 2012 10:54:37 +0200 sawyer x <xsawyerx@gmail.com> записано:
This seems like a well thought-out idea, but unfortunately I think it shouldn't be done. Dancer 2 is already completely OO and so is the DSL. The idea now is to simply keep Dancer 1 maintained as far as to let Dancer 2 be developed continually. Once Dancer 2 is ready, we'll start moving to it. It will already contain all the things people suggest to put into Dancer 1, being done more cleanly and correctly.
Moving to dancer 2 could be a big issue. And afaik dancer 2 simply is not ready. Meanwhile people may want to write modules. This approach is simple and can be used with an existing code base. -- С уважением, Роман Галеев, +7 347 2-900-145 www.ncom-ufa.ru
Hi, I think the proposed code is a good idea. It's a simple and fresh alternative to MVC but keeping some OO concept. I see it more as a proof of concept though, until it gets more fleshed out. For me it's not an issue to continue developing new ideas on dancer 1. Once dancer 2 is out, they can be migrated. What's is proposed here is different from the OO of dancer 2. Granted, it'll be easier and shorter to write on top of dancer 2, but it won't be obsoleted by dancer 2 Only my 2 cents :) Le 26 janv. 2012 à 10:13, "Роман Галеев" <ip@ncom-ufa.ru> a écrit :
На Thu, 26 Jan 2012 10:54:37 +0200 sawyer x <xsawyerx@gmail.com> записано:
This seems like a well thought-out idea, but unfortunately I think it shouldn't be done. Dancer 2 is already completely OO and so is the DSL. The idea now is to simply keep Dancer 1 maintained as far as to let Dancer 2 be developed continually. Once Dancer 2 is ready, we'll start moving to it. It will already contain all the things people suggest to put into Dancer 1, being done more cleanly and correctly.
Moving to dancer 2 could be a big issue. And afaik dancer 2 simply is not ready. Meanwhile people may want to write modules.
This approach is simple and can be used with an existing code base.
-- С уважением, Роман Галеев, +7 347 2-900-145 www.ncom-ufa.ru _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
На Thu, 26 Jan 2012 12:31:50 +0100 damien krotkine <dkrotkine@gmail.com> записано:
I see it more as a proof of concept though, until it gets more fleshed out.
I think to fully flesh it out I only need to "implement" the rest of RESTful API, like put and delete keywords, and to stub other keywords as it is. Or not to stub, because one could use Dancer:: notation if needed. Altough already defined subset was good enough for me, so far.
What's is proposed here is different from the OO of dancer 2. Granted, it'll be easier and shorter to write on top of dancer 2, but it won't be obsoleted by dancer 2
Yeah, the idea behind this is ability to modularize code, like to be able just to "mount" appropriate module to the specific uri coupled with templates, with convention module mount "path" ~ views/path. -- С уважением, Роман Галеев, +7 347 2-900-145 www.ncom-ufa.ru
На Thu, 26 Jan 2012 12:31:50 +0100 damien krotkine <dkrotkine@gmail.com> записано:
I see it more as a proof of concept though, until it gets more fleshed out.
I've patched modules: now every Dancer method not overridden is passed "as is" to the caller package, and every route keyword with path is wrapped. -- С уважением, Роман Галеев, +7 347 2-900-145 www.ncom-ufa.ru
I'm using Dancer/Starman, and was looking for a place to create variables / run code that occurs once a new worker process is created. I can run code in the children process within the routes, but was looking for a way to run code just once upon the initialization of each worker process. Also, I was looking for the cleanest way to trigger code upon a graceful starman server shutdown (occurring when the master process is about to exit). Thanks!
participants (4)
-
damien krotkine -
sawyer x -
Taric Mirza -
Роман Галеев