It sounds like you'll be interested in subscriber predicates. http://docs.pylonsproject.org/projects/pyramid/en/1.5-branch/narr/hooks.html#subscriber-predicates
Personally I send emails from message queue in a separate process and so there is no conflict between these rendering environments despite both using pyramid apis. On Wed, Apr 30, 2014 at 8:00 PM, Jonathan Vanasco <[email protected]>wrote: > We've run into an annoying edge-case with our use of BeforeRender. > > Our app utilizes BeforeRender to optimize priming/loading our object cache > and data standardization. It's awesome and works great. > > We recently noticed some odd bugs and a general slowness from caches that > weren't primed properly. > > After spending most of the day debugging code , I found the culprits: > - last month we introduced some code to render template partials via > pyramid.renderer's `render`. > - our transactional emails calls `render()` as well. > > Here's where the problem kicks in: these call to `render` expectedly > trigger the `BeforeRender` event. This makes perfect sense. > > There's no way for Pyramid to know the difference between an email/partial > template and a "repsonse oriented" render. > > So we need to figure out a way to render these edge cases without > triggering BeforeRender, and consequently maintaining the "BeforeRender" > for the "response oriented" events. > > I looked into trying to expose an eventless way to render items -- but > under the hood `render` calls `RendererHelper.render`, which is used by > every render method and has the BeforeRender event hardcoded. > > the only options that come to mind are : > > - build a custom render facility that mimicks the pyramid render > environment, but obviously isn't render() > > - monkeypatch an eventless render tool into pyramid_renderers, and keep a > close eye on the original package to ensure compatibility > > both of these seem to have a bit more overhead than i'd like. i'm > wondering if anyone has another approach. i'm leaning towards the first > option right now, because the mako environment isn't terribly complex. > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/pylons-discuss. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
