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/

Reply via email to