On 3/8/07, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
Previously Alec Mitchell wrote:
> On 3/8/07, whit <[EMAIL PROTECTED]> 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
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.
Framework-Team mailing list