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

[Wichert Akkerman]

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.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.