[Dancer-users] Code refactoring gotchas?

[Flavio Poletti]

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 at rimspace.net>wrote:

> Flavio Poletti <polettix at 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 at rimspace.net            ☎ +61 401 155
> 707
>               ♽ made with 100 percent post-consumer electrons
> _______________________________________________
> Dancer-users mailing list
> Dancer-users at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20100910/bcdbc35a/attachment.htm>