[Dancer-users] Code refactoring gotchas?

[Daniel Pittman]

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