Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 get a doc patch out of this so that people aren't confused in future? Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 array
value attempted, subscript -1 at
/usr/local/lib/perl5/site_perl/5.10.1/Catalyst/Dispatcher.pm line 278.
I think that's probably $c-stack being empty because there's no request
anymore.
I *think* that
$c-view('Email')-process($c);
would work, since that doesn't rely on the action call stack.
That error message is fucking awful though, and almost certainly my fault.
Proposal: first you try the -process-by-hand approach to confirm that I'm
an idiot the way I think I am. Second we discuss how to either (a) fix this
or (b) make sure it produces a non-awful error.
(even if you've already rewritten the code it'd be much appreciated if you
could try this out and see if it does the right thing - also, you then get to
point and laugh at me with a bit of luck, which may or may not be an added
incentive ;)
--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue
http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/
Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst
commercial support, training and consultancy packages could help your team.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 S Trout wrote:
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 array
value attempted, subscript -1 at
/usr/local/lib/perl5/site_perl/5.10.1/Catalyst/Dispatcher.pm line 278.
I think that's probably $c-stack being empty because there's no request
anymore.
I *think* that
$c-view('Email')-process($c);
would work, since that doesn't rely on the action call stack.
That error message is fucking awful though, and almost certainly my fault.
Proposal: first you try the -process-by-hand approach to confirm that I'm
an idiot the way I think I am. Second we discuss how to either (a) fix this
or (b) make sure it produces a non-awful error.
(even if you've already rewritten the code it'd be much appreciated if you
could try this out and see if it does the right thing - also, you then get to
point and laugh at me with a bit of luck, which may or may not be an added
incentive ;)
--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a
clue
http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/
Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst
commercial support, training and consultancy packages could help your team.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 about other things like how a long running process might effect the need to restart the sever, etc. Job queues are nice. +1 for that approach. That's exactly what I do :) Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 and then move on to serve another request. But, if you have processes to spare then why not use them? Might need to think about other things like how a long running process might effect the need to restart the sever, etc. Job queues are nice. +1 for that approach. That's exactly what I do :) Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] RunAfterRequest/delayed Catalyst view
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 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::Template') ) is called, no email is sent.
I guess that makes sense that after -detach is called, you can't forward to
any views. Or maybe there's a way around that?
Thanks in advance for any insights.
Steve Kleiman
st...@prodhub.com___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 demonstrates the issue? Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 very small test app) for either View::Email or ::RunAfterRequest which demonstrates the issue? Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ Yes, patches welcome, I'd like to see how this would work. -- Devin Austin http://www.codedright.net 9702906669 - Cell ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 ={
to =
'st...@prodhub.com',
from=
'bocks...@mac.com',
subject =
'RunAfterRequest Test',
templates
= [
{
template= 'test.tt2',
content_type= 'text/plain',
view= 'TT',
},
],
},
);
$c-forward( $c-view('Email::Template') );
$c-response-body('foo bar');
}
==
The code below with the forward INSIDE 'run_after_request' subroutine throws
the error:
[error] Caught exception in engine Modification of non-creatable array value
attempted, subscript -1 at
/usr/local/lib/perl5/site_perl/5.10.1/Catalyst/Dispatcher.pm line 278.
Doesn't matter whether the stash call is inside or outside the subroutine.
==
sub tester :Local {
my ( $self, $c ) = @_;
$c-stash(
email ={
to =
'st...@prodhub.com',
from=
'bocks...@mac.com',
subject =
'RunAfterRequest Test',
templates
= [
{
template= 'test.tt2',
content_type= 'text/plain',
view= 'TT',
},
],
},
);
$c-run_after_request( sub {
$c-forward( $c-view('Email::Template') );
});
$c-response-body('foo bar');
}
==
The Catalyst::Dispatcher code where the error occurs is the $c-stack line
below:
==
sub _action_rel2abs {
my ( $self, $c, $path ) = @_;
unless ( $path =~ m#^/# ) {
my $namespace = $c-stack-[-1]-namespace;
$path = $namespace/$path;
}
$path =~ s#^/##;
return $path;
}
==
[END]
On Apr 29, 2010, at 11:18 PM, Devin Austin wrote:
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.
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 request to the local sendmail or I write it to a store and another (non-web) process on a separate machine (or machines) manage delivering the mail. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 I'm using RunAfterRequest...it's a bunch of slow database processing that leads up to the generation of the email. So I was hoping to drop the whole bit into RunAfterRequest instead of having a cron job deal with it. Keeps all my stuff in one place and for a Catalyst newbie that's a nice thing (if it works). Steve Kleiman st...@prodhub.com On Apr 30, 2010, at 3:46 PM, Bill Moseley wrote: 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 request to the local sendmail or I write it to a store and another (non-web) process on a separate machine (or machines) manage delivering the mail. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RunAfterRequest/delayed Catalyst view
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 Email::Template paradigm used throughout my app. Also it's not just for email I'm using RunAfterRequest...it's a bunch of slow database processing that leads up to the generation of the email. So I was hoping to drop the whole bit into RunAfterRequest instead of having a cron job deal with it. Keeps all my stuff in one place and for a Catalyst newbie that's a nice thing (if it works). 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 about other things like how a long running process might effect the need to restart the sever, etc. Job queues are nice. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] RunAfterRequest/delayed Catalyst view
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::Template') ) is called, no email is sent.
I guess that makes sense that after -detach is called, you can't forward to
any views. Or maybe there's a way around that?
Thanks in advance for any insights.
Steve Kleiman
st...@prodhub.com
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
