On Sat, Jul 3, 2010 at 6:57 AM, Hans Lellelid <[email protected]> wrote: > I think it's unfortunate that Pylons > (with the help of Paste) have chosen to make this so unobvious / > confusing. In my opinion this really discourages people from writing > tests.
Yes. It keeps improving incrementally but there's always something left out, and that ends up being what somebody needs for their tests. The problem is that while custom test code can look someplace else for the objects, anything it calls will expect things in their traditional place. I generally use the SOPs only in controllers and templates, to minimize my functions depending on them. Ben wrote: > fix testing up for Pylons 1.1 Hooray, hooray. That code still doesn't address 'tmpl_context' which was the original question. Although 'tmpl_context' shouldn't really be used outside a request. However, for the sake of completeness, we should probably either create an empty context or push a dummy object that says "don't use me outside of a request". Didip wrote: > I have similar problem with app_globals. I ended up moving everything in > app_globals to meta module, which is available when running nosetests. I did essentially the same thing, making a separate model object that can be put on app_globals during runtime, but also instantiated standalone for testing the object itself. Wyatt wrote: > pylons.app_globals._push_object(config['pylons.app_globals']) I was reluctant to do that myself without an "official" recommendation that this was the right method, but I suppose it works. > (Unfortunately, and frustratingly, Paste seems to be the > popular choice in the non-Django full-featured-frameworks ... so I can > only assume that they're all going to get mired down in SOP confusion > & misdirection.) Paste is a collection of independent things (which Ian is gradually moving out of Paste to their own packages). Most Paste frameworks do not use SOPs. SOPs were created for Pylons to address the rare case of multiple WSGI applications (or instances of the same application) using shared globals in the same process. E.g., 'app_globals' is specific to the application instance, not to the worker thread, so it has to be switched as each instance is requested. Pylons chose to use shared globals due to their popularity in CherryPy, but they do raise this problem when combining applications. So if a framework avoids shared globals, it doesn't need SOPs. In some frameworks, the context is passed as action arguments, or instance attributes on the controller, or global functions that find the context and return it. -- Mike Orr <[email protected]> -- 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.
