[Framework-Team] Re: PLIP #187 for Plone 3.1
I've created a buildout for evaluating PLIP #187 at: http://svn.plone.org/svn/plone/review/dreamcatcher-plip187/ More information on the status over here: http://awkly.org/2007/12/24/preparing-plip-187-for-review/ Summary: At this point, it should be possible to checkout the buildout, build it and run the tests, which currently gives me 3 failures for CMFPlone, two of them apparently unrelated and one related but which apparently did not happen at the time I've branched. The next step is to update my CMFPlone and Marshall branches to trunk, and possibly getting rid of the PloneTestCase I had initially created. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Suggestion for adding Usecase information
Danny Bloemendaal wrote: > After having waded through a big pile of plips I often (as a less > technical oriented member) had problems determining what the actual > usecase was that it was trying to solve. I would like to suggest (when > thechcnically possible) to add such a section in a plip. I'd like to see > a real-world usecase example (for the less technical ppl) what the plip > has to solve/support/whatever. > Something like: > > Suppose someone wants to write a product that supports this or that. > Right now he has to do this or that to do this but with this plip in > place he only has to do such or so. > > Right now, the Motivation section isn't exactly that. In most cases, the > author immediately dives into technical details. > > I think it would help to have this addition? Or am I talking nonsense here? +1, I think we have been bad both on the side of use-case centric and integrator targeted information. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: preliminary results for PLIP selection & call for votes!
> To be clear, I believe the only -1 vote on #187 was primarily due to > some concerns about the shortage of detail in the PLIP text. A > concern I share. I'm hoping Sidnei fleshes out the details soon. :-) I would gladly answer any questions. The PLIP doesn't have much detail because there ain't much to be detailed. The branch achieves the first bullet under 'Proposal', and the third bullet was addressed and released in a Zope release. The second bullet has resulted in some research and I'm waiting for confirmation from Nate Aune that the proposed fix for it works. I have not addressed versioning because I didn't know there was any concern about it. I saw the comment #3 but my assumption was that whoever implemented versioning did it in such a way that it would interact correctly with WebDAV, but did not have the time to verify such assumption. Feel free to ask more questions... -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Official submission: PLIP 184, 200, 203 and 204
Ho ho ho, I'd like to officially submit for consideration for Plone 3.1 a bundle that comprises the following PLIPs (in separate packages): - PLIP 184 - additional portlets (has a dependency on PLIP 200) - PLIP 200 - Kupu formlib widget - PLIP 203 - Portlet assignments and blocking GenericSetup handlers - PLIP 204 - Content Rules GenericSetup handlers To make it easier for me to manage (and hopefully also easier for you to test), I've put these into a single buildout, based on plone.recipe.plone 3.0.4: https://svn.plone.org/svn/plone/review/optilude-plipathon-184-200-203-204 I've tried to clearly note what packages belong to which PLIP (though it should be pretty obvious). I've also chosen to branch CMFPlone to ensure that it all "just works". I've noted down in the review notes where the changes in CMFPlone are, and I've also included comments in the code in the few places I've made changes to CMFPlone, referencing the PLIPs in each case. To get the review bundle, please do: $ svn cp https://svn.plone.org/svn/plone/review/optilude-plipathon-184-200-203-204 $ cd optilude-plipathon-184-200-203-204 $ python boostrap.py $ ./bin/buildout The buildout has svn:externals in src/ and products/ to point to the relevant implementation branches. The file REVIEW-NOTES.txt[1] gives an overview of each of the PLIPs and which packages to consider for each PLIP, though I hope in the event it's fairly obvious. I've noted down which tests to look at as well, where applicable. I'm unlikely to make major changes to these branches from now on, unless I get some input from you guys or the community. The main question mark is over how we handle portlet assignment and blocking *export*, which I've put to a question over on the dev list. Implementing and testing export should be easy enough, if we deem it desirable and decide how to deal with some inherent performance problems. I have two further PLIPs to my name: 201 (UberSelectionWidget) and 202 (inline formlib validation and editing with KSS). I'll be working on those over the next couple of weeks, but they will in any case be bundled up into separate review buildouts (since 200, 201 and 202 all involve touching plone.app.form, albeit in different places). Cheers, and merry Christmas :) Martin [1] http://dev.plone.org/plone/browser/review/optilude-plipathon-184-200-203-204/REVIEW-NOTES.txt -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: preliminary results for PLIP selection & call for votes!
On Dec 23, 2007, at 12:47 PM, Raphael Ritz wrote: Andreas Zeidler wrote: [..] * Rapahel on #187 please also try to cast those asap. that said, how long do we want to wait for those missing votes and do we have a plan on how to proceed if they don't arrive? i'd suggest waiting until midnight tonight at most, i.e. one day, and then accept/reject plips by majority vote. thoughts? FWIW: I just gave a positive vote on this PLIP as I know that Sidnei knows what he is doing and any improvements on the WebDAV side should be most welcome IMHO. The more important part still remains anyway, namely the integration of Sidnei's GSoC project into the core (not sure how much work that is - maybe it's all done already. The hard part at least is already done). And to add another personal opinion here: it would be a pitty not to include the results of a positively evaluated Google-Summer-of-Code project simply because no-one thought of submitting the PLIP formally in time. Just my 2 cents. Raphael To be clear, I believe the only -1 vote on #187 was primarily due to some concerns about the shortage of detail in the PLIP text. A concern I share. I'm hoping Sidnei fleshes out the details soon. :-) Ric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: preliminary results for PLIP selection & call for votes!
Andreas Zeidler wrote: [..] * Rapahel on #187 please also try to cast those asap. that said, how long do we want to wait for those missing votes and do we have a plan on how to proceed if they don't arrive? i'd suggest waiting until midnight tonight at most, i.e. one day, and then accept/reject plips by majority vote. thoughts? FWIW: I just gave a positive vote on this PLIP as I know that Sidnei knows what he is doing and any improvements on the WebDAV side should be most welcome IMHO. The more important part still remains anyway, namely the integration of Sidnei's GSoC project into the core (not sure how much work that is - maybe it's all done already. The hard part at least is already done). And to add another personal opinion here: it would be a pitty not to include the results of a positively evaluated Google-Summer-of-Code project simply because no-one thought of submitting the PLIP formally in time. Just my 2 cents. Raphael PS: sorry for being so late - I didn't realize this was to be considered for 3.1 when casting my votes earlier this week. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] selected PLIPs for Plone 3.1
hi all, the framework team has voted on all PLIPs submitted for inclusion into Plone 3.1. it's taken a bit longer than planned, and we'd like apologize for the delay. the following PLIPs have been accepted: #184: Include more/improved portlets #187: Working Out-of-the-box WebDAV #195: Support product dependencies #196: GroupUserFolder removing #200: Kupu formlib widget #201: Improve the UberSelectionWidget UI #202: Support inline validation and editing for formlib forms #203: Manage portlet assignments with GenericSetup #204: Manage content rules using GenericSetup #205: Flexibility Associating Portlet Types and Portlet Managers #207: Allow Custom Portlet Managers #208: Adapter-Based Local Role Lookup #209: Add buildout to Unified Installer #210: Improve UI support for objects on multiple workflows #211: Enable dashboard to be locked down #212: Use jQuery Javascript Library #213: Prepare for better Syndication #215: Include new KSS versions #216: Template overrides #217: Use Adaptation for Workflow Assignment #218: Increase Restrictions, and Ability to Change, Addable Portlet Types by Interface #219: New site search implementation #220: Improve browser layer support #221: Use adaption for workflow history and status the last one, #221, actually ended up with a vote count of 0, which was made up of one +1, one -1 and three "abstained". so while it wasn't positively selected, it didn't get rejected either, and since this is just about accepting improvement proposals (as opposed to the actual implementation), i suppose "in dubio pro reo" applies... :) the following submissions have been rejected: #199: Integration of ARFilePreview in Plone core (preview of office and other binary files) #214: Merge of CMFPlacefulWorkflow into CMFPlone/WorkflowTool please refer to the framework team mailing list archive[1] for details about why we consider these PLIPs not to be suitable for Plone 3.1. merry christmas (where it applies) & happy coding, andi [1] http://lists.plone.org/pipermail/framework-team/ -- 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/ plone 3.0.4 released! -- http://plone.org/products/plone 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] results of PLIP selection for Plone 3.1
On Dec 22, 2007, at 12:22 PM, Andreas Zeidler wrote: here's a first summary of all votes cast so far by the framework team on selection particular plips for inclusion into plone 3.1: all but one of the remaining votes have been casted in the meantime, so it's time for an update: #184: +5 (5 votes) #187: +2 (4 votes) #195: +5 (5 votes) #196: +5 (5 votes) #199: -5 (5 votes) #200: +5 (5 votes) #201: +4 (5 votes incl 1 abstained) #202: +5 (5 votes) #203: +5 (5 votes) #204: +5 (5 votes) #205: +5 (5 votes) #207: +5 (5 votes) #208: +5 (5 votes) #209: +5 (5 votes) #210: +5 (5 votes) #211: +5 (5 votes) #212: +4 (5 votes incl 1 abstained) #213: +5 (5 votes) #214: -5 (5 votes) #215: +5 (5 votes) #216: +5 (5 votes) #217: +5 (5 votes) #218: +5 (5 votes) #219: +1 (5 votes) #220: +5 (5 votes) #221: +0 (5 votes) the only missing vote now is Raphael's on #187, but i suppose we can go without it, since it cannot make a difference on the outcome anymore. besides, waiting for it could take a while, since Raphael said it's possible he will be offline for a while. the official announcement about which plips got accepted or rejected will follow in a few minutes. and again, the updated compilation of all votes has been attached for reference. cheers, andi #184: Include more/improved portlets Framework team vote Posted by Martijn Pieters at December 13, 2007 - 22:10 +1, with the qualifier that I'd like the PLIP to be locked down to the 3 portlets listed there now, and that, as Martin noted, the static portlet will use the kupu formlib widget from PLIP 200. Framework team vote Posted by Andreas Zeidler at December 13, 2007 - 23:03 +1 (see http://lists.plone.org/pipermail/framework-team/2007-December/001484.html) Framework team vote Posted by Tom Lazar at December 14, 2007 - 21:28 +1 seconding martijn's limit to the three portlets and #220 Framework team vote Posted by Raphael Ritz at December 20, 2007 - 08:07 +1 under the restrictions pointed out above. Framework team vote Posted by Danny Bloemendaal at December 22, 2007 - 16:11 +1 #187: Working Out-of-the-box WebDAV Framework vote Posted by Martijn Pieters at December 21, 2007 - 22:47 +1 (low hanging fruit as the work is already done) Framework team vote Posted by Andreas Zeidler at December 22, 2007 - 10:01 -1 (see http://lists.plone.org/pipermail/framework-team/2007-December/001623.html) Framework team vote Posted by Tom Lazar at December 22, 2007 - 15:07 +1 (if the implementation should prove too invasive or too slow we can always still bump this to 3.2 but i don't see any reason to reject this plip per se for 3.1) Framework team vote Posted by Danny Bloemendaal at December 22, 2007 - 16:13 +1 #195: Support product dependencies Framework team vote Posted by Martijn Pieters at December 13, 2007 - 22:19 +1 Framework team vote Posted by Andreas Zeidler at December 13, 2007 - 23:45 +1 (see http://lists.plone.org/pipermail/framework-team/2007-November/001406.html) Framework team vote Posted by Raphael Ritz at December 17, 2007 - 13:29 +1 Framework team vote Posted by Tom Lazar at December 22, 2007 - 15:05 +1 Framework team vote Posted by Danny Bloemendaal at December 22, 2007 - 16:13 +1 #196: GroupUserFolder removing Framework team vote Posted by Andreas Zeidler at December 13, 2007 - 23:19 +1 on cleaning up and fixing broken links, but -1 on replacing existing tools (see http://lists.plone.org/pipermail/framework-team/2007-December/001507.html) Framework team vote Posted by Tom Lazar at December 20, 2007 - 13:01 I second this. Framework team vote Posted by Raphael Ritz at December 20, 2007 - 08:15 +1 on cleaning up the UI and making it use the proper API but -1 on tool removal/change. I would consider that OK for Plone 4.0 but not for 3.1. Introducing deprecation warnings, however, could be considered OK. BTW: I'm somewhat confused here myself because as pointed out in the PLIP the GroupUserFolder isn't usable since a while anyway but I simply don't know whether it could be considered safe for removal is I cannot judge whether anything still might bepend on it (most notably 3rd-party add-ons which we have promised not to break in this release). Framework vote Posted by Martijn Pieters at December 21, 2007 - 17:04 Another +1 on the UI cleanups and -1 on the risky tool removals. Framework team vote Posted by Danny Bloemendaal at December 22, 2007 - 16:14 +1 on UI cleanups #199: Integration of ARFilePreview in Plone core (preview of office and other binary files) Framework team vote Posted
Re: [Framework-Team] Re: PLIP184 - additional portlets
Previously Martijn Pieters wrote: > On Dec 23, 2007 1:50 PM, Martin Aspeli <[EMAIL PROTECTED]> wrote: > > > Is it an idea that this collection portlet has some kind of next/ > > > previous functionality that uses kss and ajax to get the next batch > > > inside the portlet? With kss this is almost trivial and it enhances > > > the UX of the thing. > > > > I hadn't thought of it, and I'm not sure I'll have time, but I'd be > > happy to include it if the team agrees and someone can help me with the > > implementation. > > Wouldn't that make KSS a requirement for anonymous users? I don't see why. It would just add functionality for people who do have KSS enabled. 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
Re: [Framework-Team] Re: PLIP184 - additional portlets
On Dec 23, 2007 1:50 PM, Martin Aspeli <[EMAIL PROTECTED]> wrote: > > Is it an idea that this collection portlet has some kind of next/ > > previous functionality that uses kss and ajax to get the next batch > > inside the portlet? With kss this is almost trivial and it enhances > > the UX of the thing. > > I hadn't thought of it, and I'm not sure I'll have time, but I'd be > happy to include it if the team agrees and someone can help me with the > implementation. Wouldn't that make KSS a requirement for anonymous users? -- Martijn Pieters ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP184 - additional portlets
Danny Bloemendaal wrote: On 23 dec 2007, at 01:31, Martin Aspeli wrote: Hi guys, PLIP 184 is about adding new portlets. I've got two covered and mostly complete: - plone.portlet.static[1] provides static text with a Kupu widget - plone.portlet.collection[2] provides a listing based on a collection Is it an idea that this collection portlet has some kind of next/ previous functionality that uses kss and ajax to get the next batch inside the portlet? With kss this is almost trivial and it enhances the UX of the thing. I hadn't thought of it, and I'm not sure I'll have time, but I'd be happy to include it if the team agrees and someone can help me with the implementation. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP184 - additional portlets
On 23 dec 2007, at 01:31, Martin Aspeli wrote: Hi guys, PLIP 184 is about adding new portlets. I've got two covered and mostly complete: - plone.portlet.static[1] provides static text with a Kupu widget - plone.portlet.collection[2] provides a listing based on a collection Is it an idea that this collection portlet has some kind of next/ previous functionality that uses kss and ajax to get the next batch inside the portlet? With kss this is almost trivial and it enhances the UX of the thing. Danny ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP184 - additional portlets
Geir Bækholt · Jarn wrote: On Dec 23, 2007, at 01:31 , Martin Aspeli wrote: The PLIP also mentions a better RSS portlet. I won't be able to do that, but rumour is that Wichert has done it in the "feedmixer" portlet already. Is that correct? If not, do we have any other volunteers? Feedmixer is a better RSS portlet, and should cover most usecases. It aggregates multiple feeds to one (and includes a "more…" listing.) , but you can easily cover the simple usecase of a single feed as well. This is what I send to Martin earlier: Feedmixer is not a 'better' portlet (even if its implementation actually is better). Feedmixer serves a different purpose: a portlet and page that shows data aggregated from multiple feeds. That is quite different than what the standard RSS portlet does: that makes it extremely easy to add a portlet for a single feed. The use cases differ enough to warrant separate portlets. The main problem people have with the current RSS portlet is that it does not work for anonymous users, or it only works as long as there are authenticated users active as well. I fixed that in svn a while ago but that hasn't made it into a release yet. based on that we'll keep feedmixer as a separate product. 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
Re: [Framework-Team] PLIP184 - additional portlets
On Dec 23, 2007, at 01:31 , Martin Aspeli wrote: The PLIP also mentions a better RSS portlet. I won't be able to do that, but rumour is that Wichert has done it in the "feedmixer" portlet already. Is that correct? If not, do we have any other volunteers? Feedmixer is a better RSS portlet, and should cover most usecases. It aggregates multiple feeds to one (and includes a "more…" listing.) , but you can easily cover the simple usecase of a single feed as well. - but i also think Wichert has fixed the default RSS portlet so it actually works now. I don't have much of an opinion on which is better for default Plone. I guess this may come down to dependency on third party libraries? -- ___ Geir Bækholt · Managing Director, Jarn · www.jarn.com Plone Solutions, Development, Hosting and Support __ Plone Solutions is now known as Jarn www.jarn.com/name-change ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
