[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rocky Burt wrote:
> On Sat, 2007-06-01 at 16:32 +0100, Hanno Schlichting wrote:
>> Hhm, I'm not sure what the best way is here. Personally I would like to
>> get rid of as much of Acquisition as possible, but obviously we need to
>> be careful here.
> 
> +10 here

Fuggeddaboudit -- this is Zope2, and acquisition is still crucial (and
will remain so for the foreseeable future).  Tools-qua-utilities *need*
wrapping in order for Zope2's security machinery to operate.  If Five's
"local utility" bits don't arrange to wrap their own registered
utilities (not those gotten by "acquiring" from above), then we need to
change them to do so.

>> Thinking about it a bit more, I would say, that if you need to aq_wrap a
>> tool in order for it to function as expected, you shouldn't really
>> register it as a utility in the first place.
> 
> Maybe, maybe not.  I would go as far as to say that 75% of the time when
> a tool needs an acquisition context, all it really needs it for is to
> get to the portal object.  From there it can usually do whatever it
> wants.  Why not clean up the tools a bit so that instead of trying to do
> something acquired, it looks up the portal and goes from there instead?
> Or maybe that's biting off a bit too much?
> 
> I recently had the problem where in certain circumstances if you're
> inside the mutator or accessor of a python property, then aq is not
> maintained which prevented me from doing tool lookups that I needed to
> do (Plone 2.5 / CMF 1.6).  What I ended up doing was calling
> getToolByName(zope.app.component.hooks.getSite(), 'sometool').  Of
> course if we make getUtility(ISiteRoot) work, we could use that instead
> of the zope.app.component.hooks.getSite() rule.  Although, I'd love to
> see utility lookups from one utility to another just use ISite and note
> ISiteRoot as it would make overriding tools in "sub-portals" much
> easier.
> 
> 
>> In the end a utility is defined as something that does not need a
>> context to do it's work. 

You are confusing "context" here -- the utility doesn't need to have an
"adapterish" context, but it *does* need to have "containment" context
- -- that is why it is "local" in the first place.

> Hm... I'm not convinced of this, for me using "local" utilities versus
> global utilities is about being able to get to the portal somehow.
> Perhaps I'm mis-using local utilities?

I don't think so.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFn+/O+gerLs4ltQ4RAm26AKCFWasXbK4htOKfGsQ/N3tZAsSuPACg3KWi
LmDHaqjso+cvQVKW93ImZEY=
=R+be
-----END PGP SIGNATURE-----