Turning it into a role and making it optionally be applied would be a nice to
have (i.e. so people could turn it off if needed).
It working seamlessly with apps which already use the (old) plugin is a *must*
have (but to be fair - maybe we can just filter U::P::U::Encoding out of the
plugin
On 8 Mar 2013, at 04:57, Francisco Obispo fobi...@isc.org wrote:
They are installed by default under the lib/ directory, I'm not a big fan of
that setup,
Nobody is a big fan of this setup.
This pre-dates Module::ShareDir.
If someone was to fix things such that new applications installed
On 5 Mar 2013, at 14:46, E R pc88m...@gmail.com wrote:
My use case is that I am developing a second view class, but it can't handle
all of the templates yet. So the logic I am putting into the end method is:
if (View2 can handle template $c-stash-{template}) {
$c-stash-{current_view}
On 10/03/13 19:58, Tomas Doran wrote:
Does anyone have a strong opinion on this being added to their app by default?
Does anyone have an app which needs you to NOT load the unicode plugin? Speak
now, or you're gonna have a bad time :)
My views already encode the response body if required. If
Yes,
By we I mean: Internet Systems Consortium (ISC), internal applications.
We use debian in some of our platforms, and we package our software into a
private repo.
Apologies for the confusion ;-)
On Mar 10, 2013, at 3:00 PM, gregor herrmann gre...@debian.org wrote:
I'm not aware of
On Sun, Mar 10, 2013 at 2:06 PM, Peter Flanigan p...@roxsoft.co.uk wrote:
# Only touch 'text-like' contents
return $c-next::method(@_)
unless $c-response-content_type =~ /^text|xml$|javascript$/;
smells bad, it will apply to text/x-json but not application/json
The code
