[Dancer-users] Code refactoring gotchas?

[Daniel Pittman]

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