Re: [Framework-Team] beta1 release timing
Wichert Akkerman schrieb: [..] The last one is a decision that we need to make. 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. For completness sake, here is my opinion: 1. don't deprecate 'getToolByName' for now. Although we should try hard to not use it in Plone/Archetypes anymore from now on way too much third-party code depends on it and we should give people some time to adopt the new way before fludding to logs with unhelpfull warnings. 2. I have no problem with delaying the beta until March 19th. Raphael 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. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
suggestion for central place to import tool interfaces from (was: Re: [Framework-Team] Effects of the tools-as-utilities branch)
On Mar 7, 2007, at 10:57 PM, Martin Aspeli wrote: Hi guys, hi, I believe Jens merged, and we now have some interesting side- effects... first of all i'd like to say i agree with martin that it's great this branch is merged so we can finally start using `getUtility()`. however, having started to do just this yesterday (in a project tomster and i are currently working on) i've noticed that a) some tools are still missing and b) it's kinda cumbersome to find the correct interface to import before using `getUtility()`, at least in some cases. while a) should be relatively easy to fix (my only question in this regard would be if it's okay to just add missing tools to `componentregistry.xml` at this point?) i'd like make a suggestion for b): how about importing all relevant interfaces into `CMFPlone.interfaces` so it'd be possible to always import all interfaces used to look up tools via `getUtitlity()` from there, no matter where they're originally from? for example, the tool i was missing in this particular case was `portal_groups`. as it turns out it wasn't registered as a utility yet, so i just added utility interface=Products.PlonePAS.interfaces.group.IGroupTool object=/portal_groups/ to the `componentregistry.xml` of my site product for now. what bothered me here was to dig through various interfaces to (hopefully) come up with the correct one to use. in this case this was slightly confusing, since plone still registers its own groups tool in its `initialize()`, which is based on the one in `Products.GroupUserFolder.GroupsTool`, but in `toolset.xml` the one from `Products.PlonePAS.tools.groups` is used, and that's also the one used in an instantiated plone site. not exactly knowing the details of the relationship between membership and groups tools from cmf, plone, groupuserfolder and plonepas this was rather confusing, like i said. so what do you think about having a central place to import those tool interfaces from so developers can avoid having to go read a lot of code to find the right one? maybe a dedicated place like `CMFPlone.interfaces.tools` would be better than cluttering `CMFPlone.interfaces` itself, but imho this would be a great convenience... cheers, andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ please sign the climate wake up call @ http://www.avaaz.org/ PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Base tag
Geir Bækholt · Plone Solutions wrote: On 6. mar. 2007, at 01.23, Martin Aspeli wrote: My point in the bug thread is that I *think* the solution is to make sure slashing of links is always consistent: if it's folderish, put / at the end, if not, don't. I can confirm that the solution is to always have a trailing slash for folderish content. That way we can : 1) keep the base tag if we want, with no harm 2) remove the base tag if we want, with no harm 3) never get anchor problems I would vote for keeping the base tag anyway, as it would make the site not break if someone makes a wrong link somewhere. Another possibility to help this would be to make all folderish content redirect to get the trailing slash, like Apache does. +1 on redirecting Historically the Zope mantra has been to return data rather than redirect to save the overhead of processing an extra request. Plone is a complex application and I suspect this overhead is negligible compared to rendering a page. Matching Apache's behaviour would make things conceptually simpler. INonStructuralFolders should probably not have a trailing slash appended. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[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
