Using Catalyst::Plugin::RunAfterRequest to handle some housekeeping after I've
executed $c->detach. Works great, but...
What I'd really like to do is be able to dispatch an email from within the
RunAfterRequest subroutine using Catalyst::View::Email. But when $c->forward(
$c->view('Email::Templ
I posted this a while ago but I think it got lost in that tumultuous
"Alternatives to Catalyst" melee. Figured I'd try again now that things have
calmed down a bit
Using Catalyst::Plugin::RunAfterRequest to handle some housekeeping after I've
executed $c->detach. Works great, but...
What I
On 30 Apr 2010, at 07:00, Steve Kleiman wrote:
Thanks in advance for any insights.
No ideas I'm afraid.
However I don't see any reason why this couldn't / shouldn't work..
Could you work up some test cases (or a very small test app) for
either View::Email or ::RunAfterRequest which demonst
On Fri, Apr 30, 2010 at 12:09 AM, Tomas Doran wrote:
>
> On 30 Apr 2010, at 07:00, Steve Kleiman wrote:
>
>> Thanks in advance for any insights.
>>
>
> No ideas I'm afraid.
>
> However I don't see any reason why this couldn't / shouldn't work..
>
> Could you work up some test cases (or a very sma
Here goes...hopefully a simple test case for the RunAfterRequest oddness.
The code below works as expected...an email is dispatched.
==
sub tester :Local {
my ( $self, $c ) = @_;
$c->stash(
email =>{
On Fri, Apr 30, 2010 at 2:38 PM, Steve Kleiman wrote:
> Here goes...hopefully a simple test case for the RunAfterRequest oddness.
>
>
This is really not the response you were hoping for, but have you considered
not using RunAfterRequest? I either send email directly during the request
to the lo
That's definitely my fallback if necessary. I really like using the
Catalyst-centric option because it's easier for my brain to compartmentalize.
It keeps the email dispatching process consistent with the rest of the
Email::Template paradigm used throughout my app.
Also it's not just for email
On Fri, Apr 30, 2010 at 3:59 PM, Steve Kleiman wrote:
> That's definitely my fallback if necessary. I really like using the
> Catalyst-centric option because it's easier for my brain to
> compartmentalize. It keeps the email dispatching process consistent with the
> rest of the Email::Template pa
On 30 Apr 2010, at 23:22, Bill Moseley wrote:
Ya, it's a fine line. I tend to think Catalyst's job is to handle a
request and return the response as soon as possible and then move on
to serve another request. But, if you have processes to spare then
why not use them?
Might need to think
Thanks for the feedback, Bill, t0m. I've got some reworking to do...
-s
On May 1, 2010, at 6:19 PM, Tomas Doran wrote:
>
> On 30 Apr 2010, at 23:22, Bill Moseley wrote:
>> Ya, it's a fine line. I tend to think Catalyst's job is to handle a request
>> and return the response as soon as possi
On Fri, Apr 30, 2010 at 02:38:50PM -0700, Steve Kleiman wrote:
> Here goes...hopefully a simple test case for the RunAfterRequest oddness.
> The code below with the forward INSIDE 'run_after_request' subroutine throws
> the error:
> > [error] Caught exception in engine "Modification of non-creata
Wow, Matt. That works like a charm. THANK YOU.
No pointing and laughing from this corner. Except at myself for not setting up
a proper email dispatching mechanism. One bridge at a time.
Again, my thanks for tracking that down.
Steve Kleiman
st...@prodhub.com
On May 2, 2010, at 12:49 PM, Matt
On 3 May 2010, at 05:28, Steve Kleiman wrote:
Wow, Matt. That works like a charm. THANK YOU.
No pointing and laughing from this corner. Except at myself for not
setting up a proper email dispatching mechanism. One bridge at a time.
Again, my thanks for tracking that down.
Can we at least
13 matches
Mail list logo