Mike Orr wrote: > On Nov 8, 2007 3:14 PM, Alberto Valverde <[EMAIL PROTECTED]> wrote: >> Mike Orr wrote: >>> Plus, what if Pylons adds another SOP later? >> This is reminds me of something that I've sometimes wondered about >> pylons: wouldn't having just a single SOP where all the app's context >> can be stored simplify much the implementation? >> >> It would certainly make the API a little bit more ugly though (eg: >> pylons.app.g, pylons.app.buffet, etc..) but it would be easier to >> explain to users that everything under pylons.app is somewhat special >> and have the benefit of being just a single object that needs to be >> saved in case the app serving a request is to be paused and resumed later. > > That's a good idea. A slightly longer import is no big deal, and it's > done in the base template anyway so controllers wouldn't even notice > the difference. 'app' is not the right word though because it > connotes the Pylons application instance. app_context, sop, ... > pylons.sop has a nice ring to it. :)
Yeah, the name "app" was the first thing that popped out of my head and I'm terrible at naming ;) > But what about pylons.config? It's valid even when a request isn't > active. So something like pylons.app_context.config wouldn't quite be > accurate. The config would technically still be available since a SOP can be instantiated with a default value that is available when nothing has been pushed to it yet, though it's true that the name would not be accurate so it could lead to confusion. However, after looking at the code more closely it seems to me too much of a change since there are other objects that use them internally (WSGIRequest for example) and it might not be much of an advantage since, potentially, thirdparty libraries could also make use of them (eg: ToscaWidgets has a SOP at toscawidgets.framework) and preventing them to use their own SOP's and register their context inside pylons would couple them innecessarily. Which brings up the question? How would thirdparty libraries that make use of SOPs make sure their context is preserved when they're being used inside a generator in Pylons? Maybe pylons could provide a place to register callbacks (similar to turbogears' extensions) so thirdparty extensions could register themselves in their "pylons adapter"? Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
