[Catalyst] RunAfterRequest/delayed Catalyst view

[Steve Kleiman]

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
steve at prodhub.com



On Apr 30, 2010, at 3:46 PM, Bill Moseley wrote:

> 
> 
> On Fri, Apr 30, 2010 at 2:38 PM, Steve Kleiman <steve at 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
> moseley at hank.org
> _______________________________________________
> List: Catalyst at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100430/809f1585/attachment.htm