Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Aspeli wrote:
Kapil Thangavelu wrote:
On Thu, 12 Apr 2007 06:16:23 -0400, yuppie <[EMAIL PROTECTED]>
wrote:
Hi!
Philipp von Weitershausen wrote:
yuppie wrote:
Kapil's also right when he says that utilities by principle are
context-less components.
By principle all Zope 3 code might depend on setSite to work as
expected. We just don't pass that 'site context' explicitly to the
component as in Zope 2.
contextual lookup is very a different notion, that context implementation
dependence. utilities don't have context implementation dependencies in
zope3, the majority of cmf tools do.
Just so we are clear, can anyone point to a good example of a
not-trivial-to-change place where CMF tools have inherent dependencies
on acquisition?
Security is inherently "placeful" in Zope2: it requires being able to
verify that the logged-in user is authenticated in a user folder which
is in the "scope" of the protected resource.
As far as I'm concerned, Zope3's model is *not* intrinsically superior:
it doesn't support the use cases of the Zope2 model at all. Let's just
forget the "Zoep3 is better" mantra and find a workable near-term
solution here: if we have to re-implement / tweak some Zope3 machinery
to make it "play nice" in Zope2, then let us do so, rather than
distorting both in a misguided effort at "Zope3 purity."
>
- If that means continuing to use 'getToolByName' for traditional tools
which need Zope2 security, fine; folks who implement new utilities
which don't need that compatibility can register them as pure
utilities.
- If it's easier to hack the LSM stuff to automagically wrap those
returned utilities which implement IAcquisitionWhatever, fine; if
that means in turn that folks must use the Zope2 LSM version in
subsites, fine.
I guess the main worry is if we go down a route whereby we *always* need
a zope 2 version and a zope 3 version of some piece of code. Of
course, this is often the case anyway, but that doesn't mean we have to
make the situation worse. KSS, for example, had a set of components that
worked well across both zopes, and now needs conditional imports for its
base classes.
This is not "rape" by any stretch of the imagination; this is
"adaptation" at its best. Let's be pragmatic here, please.
The Hungarians have a colourful idea of language. :)
Martin
_______________________________________________
Zope-CMF maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
