Hi Iain, On Feb 6, 7:02 pm, Iain Duncan <[email protected]> wrote: > You can always get more stuff out of the registry in your view's init > method, making it behave like an adapter for more items. The ZCA registry > can accomplish most of what you would normally use a dependency injection > framework for, and is there as request.registry. > > Check out the online ZCA book. I've even read it described as 'dependency > injection on steroids'. =)
Thanks for your feedback. Yes, ZCA is very powerful. Although it is used extensively by Pyramid, it is very elegantly hidden and I thought it is not meant to be used by developers. A Pyramid view already works as an adapter. It adapts the context and the request. However, I did not figure out yet how to register views into Pyramid that expect more that the context and the request. Do I have to write a custom view_config decorator? One more thing. Here http://www.mail-archive.com/[email protected]/msg01851.html I read that you are working on a resource oriented CMS. Did you publish the code already? Thanks in advance, Nikos. > > HTH > > On Fri, Feb 3, 2012 at 1:44 AM, Free Ekanayaka > <[email protected]>wrote: > > > > > > > > > Hi Nikolaos, > > > |--==> On Wed, 1 Feb 2012 02:02:31 -0800 (PST), papagr < > > [email protected]> said: > > > [...] > > > >>> Assuming that a view depends on other objects to do its job, is there > > >>> a preferred or suggested way of injecting other services > > >>> (dependencies) in a Pyramid view? By "injecting", I do not mean to use > > >>> the Service Locator design pattern, i.e. let the view find its > > >>> dependencies using a registry. > > > I think it'd make sense to separate a couple of concerns here. > > > 1) General services that your view needs to make use of (aka "gateways", > > as interfaces email servers, message queues, etc.). I believe these > > are good candidates for being registered in request.register, and > > they can be easily mocked by the tests. Typically you don't need > > per-view mocks as all you probably want to use a mocked email service > > for all unit-tests of your views. [0] > > > 2) The specific model object your view is supposed to drive, like the > > ProjectRepository you mention, if I understand correctly. This is the > > second parameter that your view constructor gets (beside the > > request), and is called "context". A good way to associate context > > objects with views is via traversal [1], which can be considered a more > > flexible alternative to declarations like: > > > @view_config(route_name='project_list') > > > in your code. > > > Hope it helps. > > > Free > > > [0] As you want your business logic out of the view, and things like > > sending emails and publishing messages could be considered business > > logic, you probably don't want the view to access these gateway > > services directly, but let the model layer handle them, still via > > a (Zope) registry I'd say. > > > [1]http://readthedocs.org/docs/pyramid/en/1.0-branch/narr/traversal.html > > > -- > > 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. -- 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.
