Fwd: [Framework-Team] Re: beta1 release timing

Alec Mitchell 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.

Alec




More information about the Framework-Team mailing list