[Dancer-users] Code refactoring gotchas?

[Maurice Mengel]

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
>
>