Hi Free, Thanks for your feedback.
On Feb 3, 10: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] Yes, I agree. > 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') That's right. A ProjectRepository plays the role of a Context. Unfortunately, I have to work with a legacy SQL database and traversal is not a natural fit. It requires extra coding to setup a custom Root object where Repository instances are registered during startup. In the past, I worked on a repoze.bfg project aiming to develop an ATOM publishing server using a SQL database. The Repositories where called Collections and their contents were called Members which were essentially the two main building blocks for an ATOM publishing server. The Members were adapted domain objects. Through traversal a Collection was queried by name for a Member which was the context of a MemberView. Nikos. > > 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.
