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
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-creatable
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,
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
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 possible
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'd
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
On Fri, Apr 30, 2010 at 12:09 AM, Tomas Doran bobtf...@bobtfish.net 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
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 st...@prodhub.com 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
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 st...@prodhub.com 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
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(
13 matches
Mail list logo
