Hi Daniel, thank you for sharing your experience. Have you got thoughts and/or suggestions about using the different Dancer functions - var, session, splat, ... - outside of route subs and inside other objects? Or are you suggesting that Dancer-specific functions should be called only inside the route subs in the thin layer and the implementation part should be Dancer-agnostic? This still leaves space to refactoring in the web-specific part. Now that I think about it, why "another" object? I.e. is there a "one" object in Dancer? Last question... I haven't found much documentation about the Plugins and how they are supposed to be written/used, but I saw that others use them or discuss them in the mailing list. Did I miss the right document? Thank you again, Flavio. On Fri, Sep 10, 2010 at 12:40 PM, Daniel Pittman <daniel@rimspace.net>wrote:
Flavio Poletti <polettix@gmail.com> writes:
I'm just starting with Dancer, pointers to applicable documentation are more than welcome if you don't have time to give an extended answer.
I sometimes am in the need of refactoring code that should be shared between different routes. As an example, I could have a POST route '/do-operation' that has to perform some operations and then generate a page exactly as if a GET route '/default' had been called.
I understand that it's not possible (not advisable) to call a route from another route, so the obvious solution that comes to mind is to create a function that encapsulates all that the '/default' route action is supposed to do, then call it from the two different routes:
Generally speaking, it is a good idea to encapsulate the logic of your application outside of the routes entirely, in another object.
Then, have only a thin layer of code in the routes that does web-specific things, calls through to your application, and then presents the results in a web-specific way.
That way you can reuse your application logic with other interfaces, as well as using standard Perl OO techniques, etc, to ease things like refactoring and code reuse.
Finally, for common web things like validation, encapsulate: write a helper library (or maybe plugin) that captures what you need to do, and use that from inside the routes.
(Except the rare things that are truly universal, in which case use the mechanisms that Dancer provides to hook in before every request.)
...at least, so my experience suggests. Daniel
-- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users