[Dancer-users] Code refactoring gotchas?

Flavio Poletti polettix at gmail.com
Fri Sep 10 15:10:19 CEST 2010


Hi Maurice and all,

   taking a look at the code, there does not seem to be any reason why the
various Dancer's functions cannot be called outside route subs. With
reference to separated modules, it seems that the correct way to go is
importing Dancer's syntax via:

   use Dancer ':syntax';

and then use the various convenience functions.

Is this actually the only thing that is needed?

Cheers,

   Flavio.


On Fri, Sep 10, 2010 at 2:04 PM, Maurice Mengel <mauricemengel at gmail.com>wrote:

> Hi Flavio and everyone,
>
> i am in a similar thinking process.
>
> First, your dancer app actually does come in its own package/object.
>
> Second, to make Flavio's question more concrete: I am currently
> restructuring and put most of the code in another object outside the
> actual dancer app. So far it was very convenient to use Dancer's debug
> and log functions. Is there any particular good way to log to Dancer
> from my other object?
>
> thanks
> maurice
>
> On Fri, Sep 10, 2010 at 7:37 AM, Flavio Poletti <polettix at gmail.com>
> wrote:
> > 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
> >
> >
> > _______________________________________________
> > 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/60518b4a/attachment.htm>


More information about the Dancer-users mailing list