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

[Hanno Schlichting]

Jens Vagelpohl wrote:
> 
> On 6 Jan 2007, at 15:34, Hanno Schlichting wrote:
>> I had to change two things in CMF so far though. Here are the patches I
>> came up with:
> 
> Thanks Hanno, this is a point I wanted to bring up after getting the
> last work done: When using getUtility/queryUtility, I am assuming the
> returned utility should always considered to be unwrapped. Because
> that's what the unit tests show me. There are several places where CMF
> unit tests failed and I ended up manually wrapping the utility where I
> retrieved it using __of__, but I'm not sure if I'm expected to do it
> that way. It's clear that some tools must be wrapped in order to perform
> their function - that's why for example the method I wrote to replace
> getToolByName for untrusted code still expects a context to be passed
> along and I wrap the utility in it.
> 
> It's just a bit unintuitive that sometimes you must wrap them, sometimes
> you don't need to. For a third party coder this could turn into a major
> headache and bug bear.

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.

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.

The forced aq_wrapping is like introducing a new required context
argument in a method. You effectively change the methods signature,
which shouldn't be done without a deprecation period at least.

In the end a utility is defined as something that does not need a
context to do it's work. Registering tools as utilities that either need
an Acquisition context or even worse the request (think of the evil
self.REQUEST you see sometimes) violates that very definition of what
utilities are.

While I would really love to see getToolByName vanish as fast as
possible I'm not sure if we can do this as easily as it first looked.

Maybe we could offer those tools as utilities that are real utilities
for CMF 2.1 and start rewriting those tools that are really more like
adapters as such, removing the tools altogether or splitting them up
into utilities and adapter parts.

I know this isn't a scenario that would produce major results in the
near future considering the number of people that currently contribute
to CMF but maybe it's the safer approach.

But maybe I'm just in a bit too cautious mood right now ;)

Hanno