[Dancer-users] Code refactoring gotchas?

[Flavio Poletti]

I tend to read the SHOULD part in RFC 2119 as "strive to do this, but we're
open to hear your reasons if you don't" :-)

Jokes apart, a big thank you for your explanation, hints and... time.

All the best,

   Flavio.


On Sat, Sep 11, 2010 at 6:43 AM, Daniel Pittman <daniel at rimspace.net> wrote:

> Daniel Pittman <daniel at rimspace.net> writes:
> > Flavio Poletti <polettix at gmail.com> writes:
> >
> >> 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?
> >
> > That would generally be what I aim for, but as you found you can 'use
> Dancer
> > ":syntax"' anywhere and it will just work.
>
> Actually, let me expand on this.  I think it deserves a little more detail:
>
> The vars, session, and splat are effectively inputs to the back-end
> application, right?  vars pass data around in a web-specific way, session
> persists data across independent web requests, and splat (like params) is
> part
> of parsing the user input.
>
> So, for splat and params I would expect to pass the relevant parts of those
> pools of data into my application functions.  If the function needs to know
> the ID of the object, pass that as an explicit argument.
>
> Then when you need a command line (or MQ, or SOAP, or XMLRPC, or email, or
> ... whatever) "frob object N" tool you can just pass in the N without the
> application knowing anything about the "splat" or "params" methods.[1]
>
>
> 'vars' is *really* a web flow implementation detail.  It allows passing
> data
> between your filters and routes along a chain; that should either modify
> state
> inside the application object, or simply end up as another regular
> parameter
> to the application in the final handler.
>
>
> 'session' is probably the hardest part of this: your application probably
> needs something akin to one of these, though my strong personal preference
> is
> to design the application to have storage of its own, then use the "web"
> session side to work around the fact that HTTP is not continuous.
>
> That is, my web session will contain only the reference material needed for
> the immediate purpose of loading my application session, and maybe the few
> extra bytes of web-specific state we want to maintain.
>
> This has the bonus of making it appropriate to use a session storage engine
> like
> Dancer::Session::Cookie — although that really isn't as secure as I would
> like
> it to be.
>
> If your application session storage keys are not appropriately secure you
> would definitely want to consider something better.  Maybe I should try and
> find time to polish and release one of the versions I have sitting on my
> disk
> as a Dancer plugin...
>
>
> Finally, you didn't mention it by name, but the template stuff would also
> generally stay outside the core of my application, because that varies
> quite a
> lot.
>
> Most of the methods would return data structures, which would then get fed
> by
> the container into whatever template or presentation engine they want; the
> general idea is that the return value SHOULD[2] be in a form that you could
> represent with JSON, since that is a suitable common denominator for all
> the
> possible ways it could be presented.
>
> So, the output of that would feed into the variables part of the template
> stuff built in to Dancer and all.
>
>
>
> Anyway, I hope that clarifies how I see the roles of those various
> attributes
> in relation to your overall application.
>
> I should also add that for something small, or specialised, enough I
> wouldn't
> go to these lengths: if you are writing less than three hundred lines of
> code
> and templates then this would be too heavy, and it should just use the
> Dancer
> stuff as *the* API.  Probably.  Unless it expects to grow. :)
>
> Regards,
>        Daniel
>
> Footnotes:
> [1]  Another approach, since Dancer is wonderfully light, is to state that
> the
>     "splat" and "params" *are* your back-end API, and then provide your own
>     implementation when you need a CLI tool.  Not too terrible an idea,
>     actually, in some ways.
>
> [2]  As in the RFC2119 version of SHOULD, which is effectively "do it this
>     way, even if you don't think you should".
>
> --
> ✣ 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/20100911/3253dda6/attachment.htm>