[Framework-Team] PLIP votes stats
Hi Eric and all, FYI on the stats page on the PLIPs voting spreadsheet, the correlations for Laurence are different in his column vs. his row ... seems like something weird is going on with the formulas there. Peace, community, justice, - George ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Merged PLIPs 184, 200, 202, 203 and 204
Martin Aspeli [EMAIL PROTECTED] writes: It probably also makes sense to extend my test_configuration.py test case with some more examples that cover George's new GS syntax. This is overlapping with, but different to George's test_exportimport.xml (his tests the handles directly, mine is an integration test that actually loads a profile and then export it again). George, would you be up for that? It should be pretty simple. Hi Martin, I looked over the code -- some comments and questions: (1) Why is the line five:registerPackage package=. initialize=.initialize / added -- isn't this only to allow a package to be installable as a Zope2 product? Is this needed for plone.app.portlets? (2) The import for blacklisting allows specifying location, but not the import for assignments. Can this be broadened? (3) The export for blacklisting only exports blacklisting at the site root. This means round-trip import/export wouldn't work. I can imagine it's inefficient to crawl the whole site to look for blacklisting, but is there a way to do it? (4) The new test_configuration.py loads ZCML to register a new profile. It's fairly non-invasive (since the actual importing of the profile happens within the tests, so is undone after the tests), but the ZCML remains loaded afterward instead of being torn down. Is there a way to unregister the profile? (5) I made a small change to the docstring of _purgePortlets to make it accurate: (http://dev.plone.org/plone/changeset/19635/plone.app.portlets/trunk/plone/app/portlets/exportimport/portlets.py) (6) I haven't updated the new test_configuration.py tests because the import profile portlets.xml is already pretty packed. I could create a second profile which would make me feel more comfortable, but my worry about adding new XML into the existing test portlets.xml is that the test is testing multiple features which are entangled with each other in the same file to import, the same test setup, etc. Do you think it makes sense to create a second testing profile rather than intermix with the existing one? Peace, George ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Merged PLIPs 184, 200, 202, 203 and 204
George Lee [EMAIL PROTECTED] writes: I looked over the code -- some comments and questions: Hi, one more question: (7) The code for purging doesn't purge blacklisting for the site root (or for other items), I think it should - is that right? Peace, George ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Merged PLIPs 184, 200, 202, 203 and 204
Martin Aspeli [EMAIL PROTECTED] writes: I've merged the following PLIPs tonight: 184 - additional portlets 200 - kupu formlib widget 202 - inline editing and validation with KSS for formlib forms 203 - portlet GenericSetup support 204 - content rules GenericSetup support Woo! Nice work. =) I've made changes to - ploneout 3.0 branch (switching to maintenance 1.0 branches for plone.contentrules, plone.app.contentrules and plone.app.form) - ploneout 3.1 branch (adding plone.portlet.static and plone.portlet.collection to the buildout) How about ploneout trunk to include the static and collection portlets? The merge for plone.app.portlets was a bit tricky since I got a lot of conflicts with George's changes to the GS handlers. His tests and mine both pass without modification (almost), so that's good. However, it'd be nice if George could take a look at my changes. It probably also makes sense to extend my test_configuration.py test case with some more examples that cover George's new GS syntax. This is overlapping with, but different to George's test_exportimport.xml (his tests the handles directly, mine is an integration test that actually loads a profile and then export it again). George, would you be up for that? It should be pretty simple. I won't be able to do anything until the weekend but am happy to look at it then. I'll try to pick a key few examples that don't duplicate too much what's going on. Peace, George ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: WebDAV changes
Wichert Akkerman [EMAIL PROTECTED] writes: I've just reverted the WebDAV changes from Sidnei after playing a bit with them. I did this for two reasons: Hanno had some very good remarks that need to be addressed I tested the 3.1 tree with just Calendaring removed. Some testing there quickly revealed that there are other things broken: the default frontpage for a Plone site is no longer created properly Sidnei pointed out it would have been better to hear about these issues earlier. Are these issues ones that the framework team should have noticed? Peace, George ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: WebDAV changes
Tom Lazar [EMAIL PROTECTED] writes: as a member of the framework team (and as somebody who co-reviewed sidnei's bundle) i feel the need to speak up. P.S. I think that as a matter of process it make sense that a release manager can make / ask for a major revert for time's sake, but that the framework team should then speak up on that because ultimately it's supposed to be their decision and what they're accountable for. Peace, George ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: tomorrow's PLIP review deadline
Andreas Zeidler [EMAIL PROTECTED] writes: ... following their notes and the various discussion to come up with another opinion, albeit not reviewing things. at least, that's what i think makes sense. Among other suggestions for the process for the next review around: I think framework team members should explicitly enumerate their votes +1, -1, 0 rather than saying to follow the reviewers' votes. I know Martijn said this in this review round and it didn't seem to be a problem, but I think that step helps make sure that team members definitely read and process each other's review notes. Peace, George ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Modified PLIPs 205 and 218
Hi, After Andreas' initial review of PLIPs 205 and 218, I've made some modifications and written responses; notes are in REVIEW-NOTES.txt http://dev.plone.org/plone/changeset/19172 http://dev.plone.org/plone/changeset/19174 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP #217 #221 Comments
Alec Mitchell [EMAIL PROTECTED] writes: There are no tests and there's a fatal bug (queryAdapter instead of queryMultiAdapter, and no interface to adapt to specified). I will of course be looking at it, at the very least for inspiration, when I prepare the bundle tomorrow. Thanks for the reminder. Kapil also posted a comment on the PLIP page with a URL to update code: http://svn.objectrealms.net/view/public/browser/ore.adaptedworkflow/trunk/src/ore/adaptedworkflow ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIPs for Plone 3.1 - Flexibility with Portlet Managers / Types
Hello! Martijn Pieters [EMAIL PROTECTED] writes: One motivation behind #207 is that with the current registration proceudre, some portlets such as the Calendar will be available in every new portlet column. An alternative way to handle this issue is by using PLIP to #205 register portlets like the calendar for IColumn and IDashboard. Unlike #205 and #207 though this proposal may break backward compatibility. I like the additional flexibility of #207 regardless of this issue. We could do both, provided you give us a PLIP on this before midnight. Here is a PLIP to re-register portlets like the calendar for IColumn and IDashboard: http://plone.org/products/plone/roadmap/218. Peace, George ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIPs for Plone 3.1 - Flexibility with Portlet Managers / Types
Hi, I've submitted two PLIPs for Plone 3.1 -- http://plone.org/products/plone/roadmap/205 http://plone.org/products/plone/roadmap/207 Both would be minor changes to allow more flexibility with registering portlet managers and portlet types. PLIP #205 allows assigning portlet types to multiple interfaces of portlet managers, to give more flexibility where various portlet types are addable. PLIP #207 allows registering a portlet manager with a custom portlet manager class, but defaulting to the standard portlet manager class. One motivation behind #207 is that with the current registration proceudre, some portlets such as the Calendar will be available in every new portlet column. An alternative way to handle this issue is by using PLIP to #205 register portlets like the calendar for IColumn and IDashboard. Unlike #205 and #207 though this proposal may break backward compatibility. Peace, George ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIPs for Plone 3.1 - Flexibility with Portlet Managers / Types
George Lee [EMAIL PROTECTED] writes: One motivation behind #207 is that with the current registration proceudre, some portlets such as the Calendar will be available in every new portlet column. An alternative way to handle this issue is by using PLIP to #205 register portlets like the calendar for IColumn and IDashboard. Unlike #205 and #207 though this proposal may break backward compatibility. Clarification - it wouldn't break backward compatibility with a typical Plone setup, but if a third-party product has registered a new portlet manager that does not provide either interface IColumn or IDashboard, then it would change the portlets available to it. Despite this, I actually think it would be best to explicitly register portlets like the calendar portlet for IColumn and IDashboard rather than relying on the current convention -- that if a portlet is registered for None, it appears in all portlet managers. 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
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
