On Sun, 18 Jan 2009 20:29:40 +0100 "Dieter Maurer" <dieter@handshake.de> wrote:
Tres Seaver wrote at 2009-1-18 11:38 -0500:
... I don't actually know how this package fits in with either Z2 or Z3: Z2 apps are always able to acquire the request,
This is not the case for "localsitemanager" delivered local utilities and we therefore have had several problems.
while Z3 apps use the "separation of concerns" pattern I just outlined.
Nobody forces you to go this route.
I've never wanted a
'get_request' method in "production" code: I would consider the need for it a sign that something in the application is factored wrongly.
You could use the same arguments with respect to the global "site" ;-) But few people in Zope 3 land separate "site" dependent and "site" independent code despite some cases where the global "site" does make problems.
Using the 'reversal of dependency' (not sure whether this is the accurate English term) you always end up with a few general concepts that act as mediators. Sites are badly named 'component registries' and are part of the central zope.component module which acts as the general plug-in point, thus the dependency. The ZCA is intended to be depended on and activating registries is a part of that. The comparison of a component registry versus a request does not hold IMHO. Depending on a request is generally not good and most people in this thread acknowledged this, pointing out that they still want the flexibility. I'd be happy with a reasonable documentation pointing out that accessing a request from anywhere is definitely not intended to be turned into an *everywhere* but needs careful though. For me, if my apps domain logic can't be used in `bin/zopectl debug` (or run) without faking a request, they're broken. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development