[Dancer-users] Dancer::Template::Alloy — in core, or my own module?

[Daniel Pittman]

David Precious <davidp at preshweb.co.uk> writes:
> On Monday 24 May 2010 06:45:33 Daniel Pittman wrote:
>
>> We have been trialing Dancer, and find it pretty darn good.
>
> Glad to hear it!  Any feedback on specific features you like/dislike, or any
> suggestions? Feedback is always valuable :)

...and at the end of my email, one bit of feedback: the responsiveness of this
list is *great* and inspires a lot of confidence that y'all will step in and
help out when issues come up.


One bug, and one "feature request", so far.  No patches or formal bug reports
yet, because I spent today on other problems, but here is the outline:


The bug is that using response_content_is_deeply from Dancer::Test in
combination with an 'ajax' route, but works with 'get' in Dancer 1.1803 fails
because the Dancer::Request 'headers' value is 'undef'.


On the same front, Dancer::Test is missing a way to get the response content
so I can post-process it: I need to decode from JSON after fetching a result,
and the mechanism for doing that is only internal at this stage.

(eg: my $body = something_magic([GET => "/foo", { bar => 1 }]) or so.)


Otherwise, only that it isn't entirely clear where you should stick one-shot
initialization code like connecting a database wrapper.  I ended up just
pushing it into the module at the top level.

I think that is mostly a documentation issue, though: it isn't like it is
hard, it just wasn't clear if I had missed anything that I should be doing in
my code to make this work more sensibly.


>> The one thing we have done which is not in the current core is to use 
>> Template::Alloy in preference to the more common Template-Toolkit engine.
>> 
>> I am not super-interested in advocating other people do the same; for us,
>> it fixed some nasty bugs that caused problems without significant
>> drawbacks, but for other people it might not have the same balance.
>
> Any chance you could describe the bugs which caused you problems?  Were they
> TT bugs

TT bugs, exclusively.  Alloy is much less mysterious about calling context,
and much less prone to doing the wrong thing.

The heart of it is using DBIx::DataModel to wrap the database: that uses
"access the hash directly" as the API for reading column values, with the hash
blessed into a class that adds some additional methods.

TT gets that wrong: if it is blessed it only calls methods; TA gets it right,
and just works.

> or bugs in the way Dancer uses TT?  If it's anything we can fix, we'd
> certainly like to hear about it!

Nothing y'all have to worry about.  Your integration just worked.

[...]

> I think I'd agree that it should be release separately; we want to try to
> keep Dancer's core quite light and avoid extra dependencies.  There are
> several other Dancer::Template::* modules already released to CPAN by
> various people, so I think that would be the best bet.

Once I sort out the last hitch from upgrading my Dist::Zilla install I should
have that uploaded along with tests and all.  So, maybe tomorrow or so.

        Daniel
-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons