On Dec 19, 2007 1:29 PM, Mike Orr <[EMAIL PROTECTED]> wrote: > > > Besides being hard to understand, they are a pain to debug. That's > > > actually my concern with them. Oh, and they have weird performance > > > characteristics that have frequently caught people. > > > > I don't see any way to remove them.... but we could go back to just > > thread-locals, and tell people not to use Pylons apps in front of > > Pylons apps (does anyone actually do this???). We are incurring a lot > > of complexity with SOP's for a 0.01% use-case here... > > We should somehow support a Pylons app as a "bundle" that can be used > inside another app. > It's not done yet because there are also routing and session scenarios > that still need to be tested. > But if that's is the only reason for SOPs, I wouldn't mind making > bundled apps get that info another way. > Perhaps *they* can call a special function to get request-local info, > while top-level apps can continue using pylons.*.
I'm liking this idea more and more. It provides a standard way for people who hate SOPs and thread-locals to avoid them, without interfering with the normal use of pylons.* for everybody else. You just need a simple class to hold these things, and then provide a function or method somewhere to get it. As a bonus, PylonsApp.__call__ can pass this bundle to the Pylons Render class which I'm about to write, because it would need to pass the individual values anyway. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" 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-devel?hl=en -~----------~----~----~----~------~----~------~--~---
