[Framework-Team] Re: beta1 release timing
Alexander Limi [EMAIL PROTECTED] writes: I'm collecting stuff for the how to update your product for Plone 3 part of the migration manual that we will send product authors to. Might be a good time to create that product-developers list we have been considering for a while, too. +1. =) (Are you talking about an e-mail list?) Peace, George ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: beta1 release timing
On Fri, 09 Mar 2007 17:42:21 -0800, George Lee [EMAIL PROTECTED] wrote: Alexander Limi [EMAIL PROTECTED] writes: Might be a good time to create that product-developers list we have been considering for a while, too. +1. =) (Are you talking about an e-mail list?) Yes. :) -- Alexander Limi ยท http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: beta1 release timing
Wichert Akkerman wrote: - getToolByName gives us a lot of deprecation warnings. We can do two things: undeprecate getToolByName in plone 3.0, deprecate in 3.5 and remove in 4.0. Or fix all getToolByNames in 3.0. This is doable with some effort. The last one is a decision that we need to make. I would be really careful to toe the policy line on deprecations here if only to toe the line. getToolByName() is *incredibly* pervasive in third party product code, and breaking things just because we want to get rid of that method is silly. This is similar to the zLOG deprecation and un-deprecation. The benefits of total deprecation do not outweigh the cost. Even if fixing it in most cases is not that hard, it's time consuming. I would like the following: - Leave it now. Have it emit warnings, but preferably not duplicate warnings (i.e. for the same tool, or, better yet, for the same calling code, but that may be hard). With too many warnings, people get giant log files and more important log messages drown. - If at any point supporting the old API becomes too difficult, remove it. I don't see that happening very soon, though. - 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). Removing in 3.5 sounds completely unrealistic to me. If we find that by 4.0 most third party products that count (i.e. would be otherwise compatible) have been fixed, we can consider removal. It will take a couple of days for this to settle down, I'm leaving for a week of snowboarding tomorrow evening, so here is my proposal: we delay the beta a bit further to Monday, March 19. At that point I'll make a decision on deprecating or undeprecating getToolByName and make a release based on whatever product and package releases exist at that time. It's a shame we have to postpone the beta further, but the CMF changes require some important change in our codebase that need to be finished. But better the hit now than later. :) Note - I can't produce any new packages by March 19th (still on holiday then, back on the 21st), but my packages ought to be stable for now. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: beta1 release timing
- 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... Removing in 3.5 sounds completely unrealistic to me. If we find that by 4.0 most third party products that count (i.e. would be otherwise compatible) have been fixed, we can consider removal. +100 and someone should blog or write a tutorial about these changes and how to utilize them. -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 begin:vcard fn:D. Whitfield Morriss n:Morriss;D. Whitfield org:The Open Planning Project;OpenPlans adr:;;1309 Ashwood Ave;Nashville;TN;37212;USA email;internet:[EMAIL PROTECTED] title:Lead Developer tel;home:615 292-9142 tel;cell:415 710-8975 x-mozilla-html:FALSE version:2.1 end:vcard ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Fwd: [Framework-Team] Re: beta1 release timing
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... 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. Removing in 3.5 sounds completely unrealistic to me. If we find that by 4.0 most third party products that count (i.e. would be otherwise compatible) have been fixed, we can consider removal. +100 and someone should blog or write a tutorial about these changes and how to utilize them. Another +100 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: Fwd: [Framework-Team] Re: beta1 release timing
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 Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
