On Sun, Mar 10, 2013 at 2:06 PM, Peter Flanigan 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 that I use o
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 wrote:
> I'm not aware of anything like this in
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. I
On 5 Mar 2013, at 14:46, E R 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} = 'View2'
On 8 Mar 2013, at 04:57, Francisco Obispo 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 their stuff
to
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 lis
