[Dancer-users] Code refactoring gotchas?
polettix at gmail.com
Fri Sep 10 13:37:29 CEST 2010
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,
On Fri, Sep 10, 2010 at 12:40 PM, Daniel Pittman <daniel at rimspace.net>wrote:
> Flavio Poletti <polettix at gmail.com> writes:
> > I'm just starting with Dancer, pointers to applicable documentation are
> > 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
> > different routes. As an example, I could have a POST route
> > 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
> > 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
> web-specific way.
> That way you can reuse your application logic with other interfaces, as
> as using standard Perl OO techniques, etc, to ease things like refactoring
> 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
> 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 Pittman ✉ daniel at rimspace.net ☎ +61 401 155
> ♽ made with 100 percent post-consumer electrons
> Dancer-users mailing list
> Dancer-users at perldancer.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dancer-users