Martijn Faassen wrote: > > * rdb:provideConnection wasn't removed. On a second thought, this > > directive also contains deployment information relevant to the system > > administrator (the DSN) that should not reside in Python code. > > I can see this would be hard to remove.
Well, in the end this does just a utility registration as well. But first it also instanciates a database adapter with the DSN > Note that I don't think RDB > deployment information should be in ZCML either, though. Perhaps, perhaps not. This isn't the focus of this proposal. > > * class/implements and class/factory weren't removed -- yet. I guess > > removing these might be a bit controversial. I'd therefore like to take > > this opportunity to bring this topic up again and to give everyone a > > chance to look at the proposal once again, before I start spending lots > > of time on the implementation. > > > > I'm okay with this moving to top-level, though a depreciation period > might be in order, as this, I think, is in common use. *Of course* there are deprecation warnings for everything I changed, nothing is changed without backward compatability for the usual 12 months. Note that class/implements will move the top level whereas class/factory will disappear since the top-level factory directive was also removed. > > If no one objects to the branch as it is, I will merge it on the weekend. > > Before this merge goes through, I would propose the following steps: > > Take the document and edit it so it's a clear guide for what you should > do with broken directives. Broken directives? Currently there's only one, browser:addview (as the proposal states), and I took the liberty of removing it. It was broken and had no tests. All other directives still work, they just generate deprecation warnings. > I.e. for browser:localUtility we want to > exactly specify what needs to be done to register this with the > normal content directive. Oops, I actually forgot to mention what happens with browser:localUtility on my branch. Basically, it's not removed yet because Jim's working on similar stuff and I don't want to create conflicts with his work. I updated the proposal just now. By the way, when I deprecate directives, I make the deprecation messages state what one should do instead of using this particular directive. Most of the time I print the new ZCML statement that should be used now. You should try running my branch on some of your software, you'll see them :). > After that, this document needs to be checked in under the > doc directory. I'm not sure that it is the right place. We've never so far checked any proposal into the doc directory, not even pretty brutal ones (e.g. the component architecture simplification after X3 3.0). > Finally, there needs to be a clear pointer in at least the changelog as > well as the release notes to this document. Sure, as always I'll state the URL of the proposal. Philipp ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com