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'. =) 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.
