Fwd: [Framework-Team] Re: beta1 release timing
apm13 at columbia.edu
Thu Mar 8 23:43:56 UTC 2007
On 3/8/07, Wichert Akkerman <wichert at wiggy.net> wrote:
> Previously Alec Mitchell wrote:
> > On 3/8/07, whit <d.w.morriss at gmail.com> wrote:
> > >
> > >>
> > >> - Consider some kind of compitability alias mechanism, so that when
> > >> people keep using getToolByName(context, 'portal_types') we translate
> > >> that to getUtility(ITypesTool), for as long as we need to (but still
> > >> warning).
> > >+1... I mean chrissakes.. getToolByName was supposed to be future
> > >proofing for this day...
> That probably was before people started using interfaces and the CA :)
> > Indeed and if the choice had been made to use named utilities
> > getToolByName could just be a shorthand for
> > getUtility(IBaseToolInterface, name). As it is, it could still be
> > made an alias for getToolByInterfaceName, though that's a little
> > silly.
> getToolByInterfaceName requires a dotted interface name, which is quite
> different. Some tools already need to become a named utility or use marker
> interfaces (our three catalogs for example).
> Some arguments in favour of not using getToolByName:
> - it allows you to do fun things like have local versions of utilities
> in your site
> - it allows us to move tools out of the content space, reducing the
> clutter you see with FTP, WEBDAV and in the ZMI and making it possible
> to use non-persistent tools
> to do that people should also stop using acquisition to get to a
> tool and always use a utility function.
> Of course we can keep getToolByName around for compatibility as a simple
> wrapper around getUtility, taking advantage of the utility registry we
> already have. This means that packages/products which include a tool
> will need to add a little registration magic, but all usage of those
> tools will just keep working. So there might not be a good reason to
> deprecate it, aside from the fact that CMF does and we do not want to
> stray too far from their practices.
> > >+100.... and someone should blog or write a tutorial about these changes
> > >and how to utilize them.
> > Another +100
> We need that for all changes, not just this one.
To clarify, my +100 was to whit's +100, not to the tutorial
suggestion. Though of course documentation is an unquestionable good.
More information about the Framework-Team