Jeff Shell wrote:
On 9/28/06, Jim Fulton [EMAIL PROTECTED] 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
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
