On Fri, 2010-12-10 at 18:00 -0800, Rob Miller wrote:
> Hi all,
> 
> So I've started taking a look at what it would take to port a large 
> suite of Pylons 0.9.6 apps to Pyramid.  Most of what needs to happen 
> looks pretty straightforward; we'd need to convert all of the routes 
> wiring to the new handler / action mechanisms, and make some superficial 
> changes to the code within the action methods.  Maybe a bit painstaking 
> and repetitive, but not particularly mind-bending.
> 
> There's one pattern in use that presents a bigger problem, however. 
> These apps have a shared set of controller base classes, from which the 
> actual controller implementations within the apps themselves inherit. 
> Some of what happens in these controller base classes is just additional 
> API stuff, fairly easily converted to a parallel set of handler base 
> classes.
> 
> The tricky parts, though, are the cases where these controllers have 
> overridden the __call__ method to effectively wrap the entire WSGI 
> invocation to do such handy things as logging, caching, and error 
> handling.  This isn't easy to replicate, because with Pyramid there's no 
> way to get control of the outer layers of the request processing cycle 
> like there is with Pylons (see 
> http://docs.pylonshq.com/pyramid/dev/narr/router.html).




> 
> In trying to think this through I've come up w/ a couple of ideas:
> 
> - I could write my own set of action decorators that implement the 
> desired functionality in addition to marking the wrapped functions as 
> exposed actions.  This would essentially be the same thing as stacking 
> multiple decorators around each of the functions, except that it avoids 
> having to stack multiple decorators around each of the functions.  ;)
> 
> - I could override the router itself, to allow me to keep the wrapped 
> functionality closer to the WSGI level.  Pyramid doesn't really provide 
> any hooks for this, however.  It'd be easy enough to change Pyramid to 
> fetch the router by interface rather than by class, making it possible 
> to supply an alternate router implementation, but there's a lot of code 
> in that __call__ method; I'm not terribly fond of copy/pasting large 
> blocks of code only to add a handful of additional lines to the middle 
> somewhere.
> 
> Does anyone have any other suggestions?  Opinions on the suggestions 
> I've made?  Has anybody out there thought about how to handle this 
> pattern in a Pyramid upgrade?

This is probably not a 100% solution, but have you seen
http://docs.pylonshq.com/pyramid/dev/narr/hooks.html#using-finished-callbacks ?



> 
> Thanks!
> 
> -r
> 


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Reply via email to