On 2013-05-14 Dimitar Petrov wrote:
> That's the proposition based on Bill's answer:
> https://github.com/dpetrov/catalyst-runtime/commit/391a98ed4e386af9ef11a3d4ea979f1e6a3c51f4
> Any thoughts?
Maybe the test should actually check what happens when the action
Cs? (spoiler: it works)
Just for be
Aristotle,
Yep, I fully agree with you that more meaningful config key is better :)
On Tue, May 14, 2013 at 2:24 PM, Aristotle Pagaltzis wrote:
> * Dimitar Petrov [2013-05-14 14:05]:
> > It was a reply to the whole thread.
>
> Ah.
>
> > Yeah, we could probably add a warning.
>
> I dunno. I lea
* Dimitar Petrov [2013-05-14 14:05]:
> It was a reply to the whole thread.
Ah.
> Yeah, we could probably add a warning.
I dunno. I lean toward it but maybe the devs disagree.
> I left it dispatch_on_die because it's concise with the action role,
> but I guess abort_dispatch_in_chains_on_excep
It was a reply to the whole thread. Yeah, we could probably add a warning.
I left it dispatch_on_die because it's concise with the action role, but I
guess abort_dispatch_in_chains_on_exception is more meaningful. Any other
thoughts?
If you already have your fork ready or differs from mine either
Hi Dimitar,
* Dimitar Petrov [2013-05-14 12:35]:
> That's the proposition based on Bill's answer:
> https://github.com/dpetrov/catalyst-runtime/commit/391a98ed4e386af9ef11a3d4ea979f1e6a3c51f4
not sure why you’re replying to me, I don’t see a warning there.
> Any thoughts?
Needs a more specific
That's the proposition based on Bill's answer:
https://github.com/dpetrov/catalyst-runtime/commit/391a98ed4e386af9ef11a3d4ea979f1e6a3c51f4
Any thoughts?
On Tue, May 14, 2013 at 6:35 AM, Aristotle Pagaltzis wrote:
> * Tomas Doran [2013-05-10 19:55]:
> > We should make it a config variable that d
* Tomas Doran [2013-05-10 19:55]:
> We should make it a config variable that defaults to the old behaviour
> but adjust -Devel to default it to true in new apps.
>
> This keeps back compat, but makes new apps behave 'correctly'.
>
> +1 from me.
Should there be a warning in old apps when an except
github.com/perl-catalyst/catalyst-runtime/tree/SicilianButtercup
just fork and send a PR
John
- Original Message -
> From: Tomas Doran
> To: The elegant MVC web framework
> Cc:
> Sent: Friday, May 10, 2013 1:16 PM
> Subject: Re: [Catalyst] Re: Chained and exceptions
We should make it a config variable that defaults to the old behaviour but
adjust -Devel to default it to true in new apps.
This keeps back compat, but makes new apps behave 'correctly'.
+1 from me.
t0m
Aristotle Pagaltzis wrote:
>* Bill Moseley [2013-05-10 17:15]:
>> What would the develop
* Bill Moseley [2013-05-10 17:15]:
> What would the developers think of deprecating this behavior (for the
> few that might actually be relying on this) and issue a warning if
> a config option is not set that fixes the issue?
I’ll second that, I’d love to drop some more unbreak-me boilerplate.
* Bill Moseley [2013-05-09 22:50]:
> Tricks for applying it globally?
package MyApp::Controller;
use parent 'Catalyst::Controller';
__PACKAGE__->config( action_roles => ['DetachOnDie'] );
1;
Then inherit that instead of Catalyst::Controller in your controllers.
Pre-5.90013 you n
Blast from the past:
http://grokbase.com/t/sc/catalyst/077e7jhw9g/rfc-catalyst-plugin-errorout
On Thu, May 9, 2013 at 1:42 PM, Bill Moseley wrote:
>
>
> On Thu, May 9, 2013 at 9:34 AM, Aristotle Pagaltzis wrote:
>
>> * Bill Moseley [2013-05-09 15:30]:
>> > What's the reasoning that chained a
On Thu, May 9, 2013 at 9:34 AM, Aristotle Pagaltzis wrote:
> * Bill Moseley [2013-05-09 15:30]:
> > What's the reasoning that chained actions continue to run after an
> > earlier exception?
>
> Seems like an accident of the design to me, borderline bug.
>
Agreed. Seems like something that could
* Bill Moseley [2013-05-09 15:30]:
> What's the reasoning that chained actions continue to run after an
> earlier exception?
Seems like an accident of the design to me, borderline bug.
If like me you don’t like it, Catalyst::ActionRole::DetachOnDie
__
14 matches
Mail list logo
