[Dancer-users] Code refactoring gotchas?

[Flavio Poletti]

Hi All,

   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:

sub default {
   # ...
}

get '/default' => \&default;

post '/do-operation' => sub {
   # do whatever I need, then...
   return default();
}


Is this approach save and future-proof? In particular, what are the
constraints of using the different Dancer functions - e.g. var, session,
splat, ... - inside a sub that isn't "installed" as a route action in the
way all the examples report?

To give a bit of perspective to my concern, I heard a lot about
Devel::Declare and related stuff that plug in during the parsing phase, and
I wouldn't like to incur in problems by not adhering to some "best
practice", whichever it is (e.g. use HTTP redirections to force the browser
to send a new request for '/default', but I would like to avoid this).

Thank you,

   Flavio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20100910/689cdacf/attachment.htm>