Daniel Pittman <daniel@rimspace.net> writes:
Flavio Poletti <polettix@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@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons