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 > 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 <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Framework-Team mailing list [email protected] http://lists.plone.org/mailman/listinfo/framework-team
