[Zope3-Users] Re: "So you've just downloaded Zope 3.3...."

[Philipp von Weitershausen]

Jeff Shell wrote:
> On 9/28/06, Jim Fulton <jim at zope.com> wrote:
>> Jeff Shell wrote:
>> > ... now what?
>> >
>> > I just tried moving some work over to Zope 3.3. Already things are
>> > blowing up.
>>
>> What do you mean by blowing up?
>>
>> We certainly tried to make 3.3 backward compatible.
>>
>> Jim
> 
> One blow-up instance was on something that was marked deprecated (a
> vocabulary that used `zope.app.utility.vocabulary.UtilityVocabulary`
> as its factory).

How? can you provide a traceback? Like Jim said, we tried having 3.3 be 
backward compatible.

> Strangely, I never saw that deprecation warning, or I
> would have fixed it a long time ago. It looks like deprecated items
> referenced in ZCML wouldn't trigger the warnings in Zope 3.2, whereas
> Python based importing/referencing would.

Hmmm. Weird. Can you reproduce this? If so, please file a bug.

> That said, I still don't really know much about what's new and
> special.

Ugh, that's bad. I'm sorry if we've been unclear. Does 
http://kpug.zwiki.org/WhatIsNewInZope33 help?

> I see a lot of things in the Wiki in proposals, but the
> proposals don't always mirror final implementations, so sometimes it's
> a bit of a guessing game if one even has that to go on. Only a few of
> the proposed ZCML reductions went into play, correct?

I just checked and the "Implementation status" section is correct 
regarding Zope 3 ("trunk" refers to 3.3 though).

I admit, though, I coudl've done a better job updating the proposals 
after having implemented them. Without moving the blame elsewhere, I 
think we should consider a more formal proposal process again, like I 
suggested once. Python PEPs and Plone PLIPs seem to work very well.

> It would be nice if there was at least a small document that went
> through deprecated items and covered how to migrate away from them -
> separate from the change log or proposals.

I've tried to emit helpful deprecation warnigns that dont' just say 
"this is deprecated" but also say "use XYZ instead". The proposals 
should also document this. What is it that you're particularly 
struggling with?

> Now, here's the strange one:
> 
> What happened to Tools? `zope.app.component.browser.tools`? I'm not
> even sure what tools were,

We weren't either ;) so we got rid of them.

> but we used them in some places in our code: most of that code being
> done over a year ago against Zope 3.1 in a time crunch. I'm not sure
> why we used those directives/interface types, but it was probably
> from a book or from looking at someone else's code.
> 
> `zope.app.component.browser.tools` was never marked as deprecated as
> far as I can tell, so now I'm looking at a co-worker's ZCML that
> references the `IToolType` interface type in a couple of places, and
> uses the `<browser:tool>` directive in a couple of places. They seem
> to be completely gone now, and probably for good reason. Still, since
> it never seemed to be marked as deprecated, I had no direction for
> moving us away from its use.

Shrug. That's a bug. No removal should happen w/o deprecation. If you 
can confirm that anything was removed w/o proper deprecation, please 
file a bug.

> All I could find on the `tool` directive in the Wiki was its proposal
> page. From looking at that page, I'm not sure it's something we ever
> needed (at least, not in the form described). I'm pretty sure that at
> least one of the instances where we use it is something my co-worker
> wants to completely re-do anyway. But until he gets back, what do I
> replace those directives with? Are they a localUtility?

Local utilities are much more light weight now. All you need is a 
<class> directive (like with any other persistent object). Registration 
happnens through the "Registration" tab in ZMI. Tools were a concept 
based on local utilities that seemed very much overengineered.

HTH
Philipp