Jens Vagelpohl wrote:
> On 7 Jan 2007, at 14:26, Martin Aspeli wrote:
>> I didn't realise we would fully deprecate getToolByName() quite yet,
>> though. I must admit I haven't been following your checkins, for lack
>> of time (and since you're surely more qualified than me in this work
>> in any case).
> The thread I pointed out clearly spells out the deprecation and the
> DeprecationWarning. I'm somewhat surprised how DeprecationWarnings are
> an issue. Clearly, in the past the Plone developer community hasn't been
> too concerned about DeprecationWarning messages.

I'm fine with deprecating getToolByName. This will spit out tons of
deprecation warnings but those can be fixed (and I know I'm probably
going to be the one doing most of that work for Plone core ;))

As a side note, I tried to bring Plone 3.0 into a state where it doesn't
spit out deprecation warnings anymore and while I haven't been
completely successful it has gotten a lot better than it used to be.

>> However, surely, if we agree that it's premature to do so, commenting
>> out the line that sends a DeprecationWarning won't be much of a change?
> I don't agree. I vote for keeping it in. There is no other obvious way
> to alert developers of this change. Besides, that's _the_ way
> deprecations have always been handled. Why should this one be different?

This one is no different IMO.

> Anyway, I propose the following:
> - the tool work to make them less dependent on acquisition is a good
> idea, but it's out of scope for the part I volunteered for. Others are
> welcome to step forward.

Yep, I feared that ;)

> - I'll continue with the work the way I have been doing it so far,
> there's just a couple small tools left and invocations in Yvo's browser
> view classes.
> - I'll be happy to mark those places in the code where I had to
> manually wrap after a straight getUtility/queryUtility call so these
> places stand out as a reminder to do something about it.

OK, after all I think this approach is not that bad. My current testing
of the CMF branches against Plone trunk shows only one major problem and
about two minor places where we would need to adjust some code. The
major problem is that the skin isn't set properly on the thread right
now in the tests, so skin Acquisition magic doesn't work, which results
in some hundred test failures for CMFPlone.

> - *However*, I won't touch any more code until we have some consensus
> here.
> Don't get me wrong, even if we come to a conclusion that spells "throw
> away the branch" or "rewrite it all" I don't care, I just want some
> final word and no more re-opening of discussions. Anything else is
> analysis paralysis and a waste of time.

OK, you get my +0.5 on moving forward.

In the end this branch will bring us a big step forward towards Zope3
adaptation and all the benefits that result from it.


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to