Dancer::Template::Alloy — in core, or my own module?
G'day. We have been trialing Dancer, and find it pretty darn good. 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. Anyway, as part of that I wrote[1] Dancer::Template::Alloy, which is pretty much the Dancer::Template::TemplateToolkit module with the names changed. Is this something y'all would want to pull back into the Dancer core distribution, or should I throw it to CPAN under my own name? I see most of the other engines have gone as their own distributions, so I suspect this one should too, but wanted to ask the developers first. Daniel Footnotes: [1] Mostly search-and-replaced, to be honest. -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons
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 :)
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, or bugs in the way Dancer uses TT? If it's anything we can fix, we'd certainly like to hear about it!
Anyway, as part of that I wrote[1] Dancer::Template::Alloy, which is pretty much the Dancer::Template::TemplateToolkit module with the names changed.
Is this something y'all would want to pull back into the Dancer core distribution, or should I throw it to CPAN under my own name?
I see most of the other engines have gone as their own distributions, so I suspect this one should too, but wanted to ask the developers first.
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. Cheers Dave P -- David Precious <davidp@preshweb.co.uk> http://blog.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/identica www.lyricsbadger.co.uk "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
David Precious <davidp@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@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons
participants (2)
-
Daniel Pittman -
David Precious