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/