Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On 2/26/11 9:22 PM, Ross Patterson wrote: Alec Mitchellale...@gmail.com writes: On Thu, Feb 24, 2011 at 10:36 AM, Hanno Schlichtingha...@hannosch.eu wrote: On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddyele...@umich.edu wrote: Feel free to respond over email or just edit the document: http://dev.plone.org/plone/wiki/PlipProcess Great work! It seems likely that this process will require a also larger team for any given release (particularly given the historic attrition rate of team members over the course the review process), along with a reasonable mechanism for members to opt-out of a particular cycle if needed. Definitely. One of the larger motivations for this change is to be less impacted by FWT attrition. As we discussed it, the FWT would become more of a framework *pool* allowing members to get busy and then come back later. Have we spelled out the process for bringing in a new FWT member as needed? Hi, at the risk of repeating myself: This all reminds me very much of handling submissions to scientific journals. They appear in regular intervals and have a review process in place to decide what goes in. One difference there, however, is how the review process is organized. Usually, you have one or several editors (think framework team) who receive submissions and do a first scan to see if a submission is within scope at all. If so, they typically ask one or several (three is quite common) peers to take a closer look and to provide a written review. Based on those review reports the editor(s) then decide about acceptance. So one major difference to our current process - if you compare the framework team to an editorial board - is that the FWT members would not need to do all the reviewing in detail but rather organize and judge the reviews. Who gets asked to provide a review is decided on a case-by-case basis and in practice adds up to many more than on the editorial board. Maybe such a model could work for us as well? Raphael Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Fwd: Re: [Plone] #9288: Improved commenting infrastructure
Timo Stollenwerk wrote: Hi, Elizabeth came across a problem with p.a.discussion during her PLIP review: Authenticated users are currently not able to post a comment, they need the Member role to do so. Do we also want authenticated users to be able to post comments? Shall we just check for the Reply to Item permission? I would like to hear other opinions before I start to refactor the code. A general note here: I've always been under the impression that guards for actions like the one here should be based on permission rather than role. That's what counts in the end. The role permission mapping is site policy and can be anything in principle. What kind of message should users without the appropriate permission see? The log-in button is kind of silly if the user has a login, but not the appropriate permissions to post a comment. That's somewhat tricky as there is no way to predict the privileges an anonymous user would have should (s)he log in. So something like the current behavior is probably as good as it gets - no button/message if discussion is disabled - a login button if discussion is allowed but user is anonymous - for authenticated check the 'Reply to item' permission That leaves room indeed for the case there you offer people to login to comment and then they might still not be allowed to do so. In such a case we could state explicitly that the current user does not have the rights needed and maybe include a link to contact site administration asking to consider changing this. Just my 2 cents, Raphael Cheers, timo Original-Nachricht Betreff: Re: [Plone] #9288: Improved commenting infrastructure Datum: Wed, 08 Dec 2010 04:30:48 - Von: Plone disc...@antiloop.plone.org Antwort an: disc...@antiloop.plone.org CC: plone-collec...@objectrealms.net #9288: Improved commenting infrastructure +--- Reporter: timo|Owner: timo Type: PLIP| Status: reopened Priority: minor |Milestone: 4.1 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by eleddy): Replying to [comment:50 timo]: Nice work! I am super gung ho about authenticated being able to comment. In default installs you will rarely see authenticated users who aren't members and in custom environments using the member role is unlikely. Curious what others think. Thanks! ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] New releases in the Plone 3.3 series
On 10/5/10 9:46 PM, Geir Bækholt wrote: The Plone 3 series has run for a longer time than anticipated, but there is still a demand for new releases. Our awesome release manager, Wichert, has, after a long series of successful releases, stated that he unfortunately doesn't have the time available any longer to continue as Plone 3.3 release manager. First of all I would like to thank Wichert for an exceptionally well done job. I think Plone would not be where it is today without you. That said: Wiggy, is there really no chance having you on board for the next one or two minor releases? I think that's all it takes until Plone 4 takes over. We are so close. Raphael (who has been way too quite here for reasons I might tell you if we meet in person but not in public ...) The Plone Foundation board hereby requests that the framework team appoints a new release manager for further releases in the Plone 3.3 line. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] changing name of plone.app.event?
Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 plone.app.calendar is even more misleading since plone.app.event provides only the event core implementation but not calendar functionality (or?). I think plone.app.event is fine since Plone developers know of ATEvent and speaking of plone.app.event as a replacement seems more logical than renaming it to .calendar. On the other hand it provides to Plone what CMFCalendar provides to CMF - I think at least. Personally, I have no particular preference. And never ever ask or listen to a German when it comes to naming things in English ;-) Raphael My 2cents, Andreas Johannes Raggam wrote: Dear Framework Team! The name plone.app.event for the event improvement package (see: http://dev.plone.org/plone/ticket/10886 ) was proposed by me at the cathedral sprint in Cologne. But since then I often think that this wasn't the best possible name. It's too ambiguous because it may impose some zope.event like event-machinery as purpose. Would the FWT agree to change it to plone.app.calendar and eventually create an additional package called plone.calendar for general purpose tools and interfaces? calendar seems a good name to me because among other reasons some parts are modeled after the RFC2445 (iCalendar) specification. This is the last possible moment to change the name before plone.app.event would possibly released with plone4.1. Thanks and all the best, johannes raggam ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team - -- ZOPYX Limited | zopyx group Charlottenstr. 37/1 | The full-service network for Zope Plone D-72070 Tübingen| Produce Publish www.zopyx.com | www.produce-and-publish.com - E-Publishing, Python, Zope Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJMoLHuAAoJEADcfz7u4AZjWFULv0WEWyzJvSp6rrns9W9Vr6aw q1OcgDfJClL5Zy0MMNeOzS1r9ZOAv9WxR/Xo79Dax7d3pBN9aMZnUciRBRyvnzQx no6yJHtnrRRrNDrBubtwK+Soyu0HpoL+LtX4tVw3WAAmtzUwqO4dU4KrHYN0pMlx UnXR/ajQZMThJl9wC94JH+rXhZ3sEoQluOJLLHvUOqfo6tJYK/flwBEOnty0esye WSsvTIgLh+wmhC9kDReIXWSUhf0cyypjQLZMYyuz74F7wnVxeHqhV4+pl1qWwTtN OrvW/82f0Gv7BRxg9VFTQQ9FGctTLA9k0EgwU37idWRYhIZjIORFBYbdzYmZrNI5 4Oxi8a7oj52Lo3RWthM1AJZEpgjZ19+A9xUnd46dZCNi7SPo8CRs4ZKrnMn7hgUQ zJkL6YGq1ZR4929pzlGrzlv4/YwMkRsONEsaKcXIP4WWJpjv8oRqWbP42ZGVitR7 i2c/6UON/JhWqxWSIUvVsBjRjbv5OkY= =MLyt -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Zope 2.13 PLIP ready for review
Hanno Schlichting wrote: On Mon, Sep 13, 2010 at 12:35 AM, Alexander Limi l...@plone.org wrote: Do we expect Plone 4.1 / Zope 2.13 to be using Python 2.7 by default? (makes sense to me, but not sure if it has other implications that I'm unaware of) See http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip10776-zope213.txt where it says: Not in scope While Zope 2.13 supports both WSGI and Python 2.7 it is not part of this PLIP to support either of them. Support for these might be added in Plone 4.2. In order to support Python 2.7 properly, there's more work to be done and this really needs more testing. I know of some buildout recipes that aren't compatible yet and I expect other commonly used libraries to need some minor updates. I'd rather see the community try it out and fix the problems one by one before we claim official support for it. Just clarifying: this means we have code that runs on 2.6 but breaks on 2.7. @Hanno: any gut feeling already how many issues/idioms we are looking at? Should we start collecting those and let people know how to become future proof? (or do have that anywhere already and I simply missed it?) Raphael Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Zope 2.13 PLIP ready for review
Laurence Rowe wrote: [..] While I would like to see Python 2.7 compatibility in a later Plone 4.x release, I would be uncomfortable requiring it during the 4.x line without very good reason I don't think anyone suggested *requiring* it still it would be nice to *support* it - at least in the not too far distant future. Raphael - Python2.7 is still new and only just being picked up by distributions (Ubuntu 10.04 LTS does not include it for instance). Being able to run Plone with a vendor supplied python makes deployment much simpler. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] [Plone-developers] Upcoming Plone 4.0 releases
David Glick wrote: [..] If I recall, the main risks are that the migration may take a long time, and that the admin may not have properly configured blob-storage in their buildout. The migration itself is pretty well-tested, at least under Plone 3 -- Groundwire has migrated dozens of sites to use blobs. There may be some other concern I am forgetting? The only other concern I recall is the potential breakage of backup routines. If someone just rsyncs/copies Data.fs via cron (or the like) it will miss the binary data after the upgrade. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Notes from Joel on simplifying Plone
Jon Stahl wrote: Hi FWT! Hi Jon, thanks for posting this! For now just one comment from my side: [..] - The apache-style buildout.cfg file is inherently intimidating to new site developers. At first, they just want any easy way to install add-on products. We used to have that -- just unzip stuff into the Products folder. We need to bring back this idea: we envision a products.d folder where you can drop an egg, or a file named my.egg.cfg and it just works. This will also greatly increase our deb/rpm friendliness, since installing products via deb/rpm would just involve dropping those products in the folder. http://pypi.python.org/pypi/buildout.eggnest/ seems pretty close to that if I'm not mistaken. With a naming convention on the file name for the [eggnest] part we should be able to realize the above. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] #9310 got a baby (#9347)
Hi, responding to our comments Duco has just broken out the user registration policy part from PLIP #9310 into #9347. So we have now http://dev.plone.org/plone/ticket/9310 User registration process more flexible only covering flexible member data and http://dev.plone.org/plone/ticket/9347 Registration policy to cover the other aspect. The new PLIP shows up on http://dev.plone.org/plone/roadmap and on our spread sheet where we keep track of the voting (first one currently). I've also added our plip-advisory list to the cc of the ticket and assigned it to Duco. Hope that's it. Now we can start considering these two proposals separately. Thanks for the prompt action Duco! Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP Change Mailing List
Martin Aspeli wrote: Steve McMahon wrote: All the 4.0 PLIPs now have plip-advisor...@lists.plone.org mailto:plip-advisor...@lists.plone.org in the CC list. If you want to subscribe, visit: http://lists.plone.org/mailman/listinfo/plip-advisories Most were added in the last few minutes, so previous activity is not in the archives. Can we add it to gmane too? Yes, please. And thanks to Steve for setting this up so promptly! Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] [Plone 4] Framework team, let's talk...
Calvin Hendryx-Parker wrote: Here is the link we used to start this process: http://www.doodle.com/ucb3w2fcqieken28 Based on the responses, generally folks are available Monday and Tuesday at 2:00PM US/Eastern time. This works for me, how about the rest? Sould be OK on my side as well (except that Monday around that time I tried to establish a regular meeting with Matthew Lange in the course of mentoring him for GSoC but I'm confident we can live with that as it's just the two of us) Raphael Others can feel free to still add their preferences into that doodle calendar so we can find the optimal times. Cheers, Cal On Jun 4, 2009, at 10:21 PM, Eric Steele wrote: Alright folks... now that I'm officially official, it's time we sat down and talked. I'd like to get some sort of phone/iChat/Skype conference together. We're never going to get 11 geographically-diverse people together at the same time, but it'd be great to find something that works for the majority of us. Can I get a volunteer to get this organized? I know that the trunk team had a regular time they'd set up and only used once. Since, er... more than half...I think... of you are on that team as well, is that still an option? I definitely don't want to cut in on Hanno's time with you, but if it's there and not being used, I'm inclined to make a grab at it. ;) Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 4 dependencies
Wichert Akkerman wrote: I seem to remember the plan was to target Plone 4 for CMF 2.2 and Zope 2.11, but as you can see below that does not appear to be possible. So that means Zope 2.12 instead, right? Do we have an estimate of what that implies on our side? Generally speaking, I'm a bit uncomfortable with jumping from Zope 2.10.x to 2.12.x as this will reduce the chances of reacting to deprecation warnings which is of particular importance for all our add-on developers. I'm afraid we'll see lots of broken add-ons without prior warnings. If there is nothing we can do about this (and it seems so) we could still consider to have Plone 3.x move to Zope 2.11 with 3.4 or 3.5. Just thinking out loud (and without knowing myself how much differences there are between Zope 2.10 and 12 that do affect us) ... Raphael Wichert. - Forwarded message from Jens Vagelpohl j...@dataflake.org - From: Jens Vagelpohl j...@dataflake.org To: Zope-CMF List zope-...@zope.org Subject: Re: [Zope-CMF] Zope dependency Message-Id: 7d23df64-b4dc-4c8e-8a51-188e8b34a...@dataflake.org Date: Tue, 26 May 2009 10:57:08 +0200 X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.3 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 26, 2009, at 10:21 , Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: The CMF eggs, even on trunk, still advertise compatibility with Zope 2.10. I believe we had agreed to target Zope 2.12 with trunk - please correct me if that's wrong. If we do want Zope 2.12 I would like to go through before the first CMF 2.2 beta and do the following: - adjust all setup.py files to show the Zope2 egg as dependency, which will imply the Zope2 = 2.12dev dependency - go through and delete all BBB code for Zope versions earlier than 2.12 If anyone thinks that's a bad idea please speak up. I think we are targetting Plone 4 at CMF 2.2 and Zope 2.11 at the moment, so that would be bad for us. I'm guessing you are not aware that there already is a hard dependency in CMFDefault. In essence, I would not be setting a new policy, I would document the current situation. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkobruQACgkQRAx5nvEhZLJadACfa9oLhpOAluaPN4QNqGf8UW26 4V8AmwSNnABEZwAQwpq1XddErphVHW0o =o1v4 -END PGP SIGNATURE- ___ Zope-CMF maillist - zope-...@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests - End forwarded message - ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone-developers] The new Plone 4.0
Alexander Limi wrote: On Sat, 09 May 2009 05:09:07 -0700, Martin Aspeli [..] We'd also need to find a way to not break all existing themes. It will break (ie. slightly change) themes that reuse parts of the original Plone CSS as part of their theme. Luckily, the fix is easy: make a copy of the old CSS in your product. Or, even easier: use our underlying technologies theming capabilities and simply ship with two themes. ;-) Make the new one the default for new sites but leave existing ones alone. Other than that: +1 on the idea Raphael Few themes do this anymore though — it's mostly for the editing/authoring bits, which would still work (although they will change slightly too). Again, very easy to copy the old CSS into your theme if you want to keep the old style. It's a x.0 release, so slight breakage like this shouldn't be a big issue. A small visual refresh would be welcome, though. Plone is looking a bit last millenium. :-/ Yup. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 3.5
Hanno Schlichting wrote: Hi. While everyone is waiting for Plone 4 and its rather long timeline, some people have been thinking about how to bridge the gap between the current stable 3.x releases and the future. The general idea that seems to have met some consensus is to go for a Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5 that is similar in spirit to the Plone 2.5 release. It tries to both refresh some of our technical underpinnings in addition to some more intrusive feature changes we didn't allow ourselves in the 3.x series so far. While I like the idea in general I would be very careful not to break our promise of Plone 3.x being stable, maintained, backwards compatible, not breaking 3rd-party add-ons etc. until Plone 4 is out for a while. Just for the record: we (the Plone 3 framework team) even got some critic from the doc team for allowing http://plone.org/products/plone/roadmap/243 into Plone 3.3 as this had somewhat of an impact on the forthcoming manual. (not to mention all the printed books that appeared recently and that are going to appear soon) After quickly browsing through Hanno's list I don't see a reason to break our pattern and to call this 3.5. At first glance it seems perfectly feasible to me to introduce at least most of the changes proposed here in Plone 3.4, 3.5, 3.6. Having said that I'm not so sure this should be handled by the Plone 4 FWT alone. Regarding the release manager on the other hand I have nothing but a warm welcome and the best wishes for Eric! Glad to see you getting more involved. Of course I would have specific comments on some of those changes but this is not the place and time to do into the details I guess. Just my 2 cents, Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.5
[Do we really need to discuss this on three lists?] Martin Aspeli wrote: JoAnna Springsteen wrote: The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1. What's the significance of 3.5? Why can't this catch up be done in increments? 3.4 then 3.5 then 3.6? Because upgrading Zope versions and some of the other changes are too big for the Plone 3.x stability promise. Do we know that for sure already? Do we know how far we could get with some temporary module aliases to take care of stuff that has been moved around? My worry here is that catching up will mean a repeat of 2.5. What does that mean? That we confused people to now end ... As I understand the current discussion the general idea is most welcome. People are concerned of staying in line with our long-term promises and it seems to me that this almost exclusively boils down to a naming issue. Frankly speaking I would have no problem calling the proposed intermediate release Plone 4 and not to assign a version number to current trunk at all. AFAICS the current co-notation of Plone 4 being the all-new, all-shiny next generation of Plone is merely a project internal that we can redefine without much of a problem but doing it the other way around because we consider sneaking in a major release before the next major release that some got used to think of being Plone 4 carries the risk of creating confusion and distrust where we can't control it. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #246 ready for review (pending review notes)
Graham Perrin wrote: [..] 1. Please, for test purposes, can anyone provide a well populated folder of events? 2. If not Calendaring + p4a.plonecalendar then can we suggest any other route to .ics import? Hi Graham, thanks for testing this. Please note that this PLIP isn't about importing events from remote sites but about displaying events as ics feeds. But I do indeed understand your wish to bulk import from such files (this is the subject of the WebDAV plip BTW). When I tested this I went through the effort of generating a few events manually ... Keep us updated on any further insights you may have. Raphael Thanks Graham References http://plone.org/products/calendaring/ http://pypi.python.org/pypi/p4a.plonecalendar/ http://pastebin.ca/1337026 (expires mid-February 2010). ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Plone 3.3 review: the final verdict
Summary of reviews for Plone 3.3 as of 2009-02-15 = In short: all submitted PLIPs are ready for merging That's really great and once more thanks to all who contributed! Specifically, we were dealing with the following: PLIP 126 - links redirect ready for merging PLIP 197: Add FeedParser as external requirement instead of shipping with it ready for merging PLIP 232: Resource Registries Improvements ready for merging (Raphael notes: while we are missing one review I consider this non-critical) PLIP 234: Standardizing our use of INavigationRoot ready for merging (Raphael notes: there is still the wish to have more test) PLIP 237: Minor i18n upgrades ready for merging PLIP 238: Disable inline editing by default ready for merging PLIP 239: Adapterise the Extensible Indexable Object Wrapper ready for merging PLIP 240: Improve locking configurability ready for merging PLIP 241: Clean up auto-sort: auto-order code ready for merging PLIP 243: Replace workflow history viewlet with content history viewlet ready for merging (Raphael notes: i18n support might need some love still but that's not considered a show stopper) PLIP 246: View for rendering events as an iCalendar file ready for merging PLIP 247: Automate ZCML Loading for Plone Plug-ins ready for merging Links to further information can be found at http://dev.plone.org/plone/wiki/PLIPTallies33 For the Framework Team, Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.3 review: the final verdict
Andrew Burkhalter wrote: Can someone refresh my memory as to who is responsible for the merging and by when? As I understand it that's Wichert's job now as he is our release manager. Whether he does all the merging by himself or whether he'll ask authors for help is up to him. Raphael I see the following lists 2/14 as the final deadline on the schedule: http://plone.org/support/forums/announcements#nabble-td1490066 Thanks! Andrew On Sun, Feb 15, 2009 at 12:42 PM, Raphael Ritz r.r...@biologie.hu-berlin.de mailto:r.r...@biologie.hu-berlin.de wrote: Summary of reviews for Plone 3.3 as of 2009-02-15 = In short: all submitted PLIPs are ready for merging That's really great and once more thanks to all who contributed! Specifically, we were dealing with the following: PLIP 126 - links redirect ready for merging PLIP 197: Add FeedParser as external requirement instead of shipping with it ready for merging PLIP 232: Resource Registries Improvements ready for merging (Raphael notes: while we are missing one review I consider this non-critical) PLIP 234: Standardizing our use of INavigationRoot ready for merging (Raphael notes: there is still the wish to have more test) PLIP 237: Minor i18n upgrades ready for merging PLIP 238: Disable inline editing by default ready for merging PLIP 239: Adapterise the Extensible Indexable Object Wrapper ready for merging PLIP 240: Improve locking configurability ready for merging PLIP 241: Clean up auto-sort: auto-order code ready for merging PLIP 243: Replace workflow history viewlet with content history viewlet ready for merging (Raphael notes: i18n support might need some love still but that's not considered a show stopper) PLIP 246: View for rendering events as an iCalendar file ready for merging PLIP 247: Automate ZCML Loading for Plone Plug-ins ready for merging Links to further information can be found at http://dev.plone.org/plone/wiki/PLIPTallies33 For the Framework Team, Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org mailto:Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] second round of PLIP reviews
Andreas Zeidler wrote: hi, i've just had a look at the updates for all the PLIPs i originally reviewed and sent some comments. i won't be available for any further discussion as well as the ultimate counting etc, though, as we're leaving for vacation tomorrow. i'd appreciate if someone from the team could take over the spokesperson responsibilities, in particular doing the counting and reporting back to wichert on saturday (or making sure it gets done). any takers or do i need to pick somebody? :) I should be available this Saturday/Sunday (I hope) so I'll take this on. Raphael cheers, andi -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.2.1 released! -- http://plone.org/products/plone/ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.3 PLIP Bundle Review Status
Steve McMahon wrote: This is a summary of the Framework Team's 3.3 PLIP bundle review status as of Saturday: Thanks for this Steve! I'll take the liberty to update this as we move on. Raphael *Reviews Complete * Accepted: 197, 237, 238, 239, 240, 241, and now 243 and 246 as well Rejected: 234 Mixed: 126 (documentation UI issues) *Reviews Not Yet Completed:* 232, 247 *Details (complete chart at http://dev.plone.org/plone/wiki/PLIPTallies33)* *PLIP #126 http://plone.org/products/plone/roadmap/126: Link type should automatically redirect when accessed directly* Review Complete: +2 technical (qualified); -1 UI (qualified) *PLIP #197 http://plone.org/products/plone/roadmap/197: Add FeedParser as external requirement * Review Complete: +2 *PLIP #232 http://plone.org/products/plone/roadmap/232: Resource Registries Improvements * No reviews yet. *PLIP #234 http://plone.org/products/plone/roadmap/234: Standardizing our use of INavigationRoot * Review Complete: -2 *PLIP #237 http://plone.org/products/plone/roadmap/237: Minor i18n upgrades * Review Complete: +2 *PLIP #238 http://plone.org/products/plone/roadmap/238: Disable inline editing by default * Review Complete: +2 technical; +1 UI *PLIP #239 http://plone.org/products/plone/roadmap/239: Adapterise the Extensible Indexable Object Wrapper * Review Complete: +2 *PLIP #240 http://plone.org/products/plone/roadmap/240: Improve locking configurability * Review Complete: +2 technical; +1 UI *PLIP #241 http://plone.org/products/plone/roadmap/241: Clean up auto-sort: auto-order code * Review Complete: +2 *PLIP #243 http://plone.org/products/plone/roadmap/243: Replace workflow history viewlet with content history viewlet * Review Complete: +2 *PLIP #246 http://plone.org/products/plone/roadmap/246: View for rendering events as an iCalendar file * Review Complete: +2 *PLIP #247 http://plone.org/products/plone/roadmap/247: Automate ZCML Loading for Plone Plug-ins * Review Incomplete: +1 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP #126 ready for review
Andrew Burkhalter wrote: snip [..] Just for the record, this was broken for a brief time on our branch due to some jostling around of language, but was resolved in the following changeset: http://dev.plone.org/plone/changeset/24272 Yup. confirmed. Sorry, but obviously I had gotten this intermediate version before getting on a plane the other day. I hope that lies w/in your as of 2009-01-16 range (e.g. it was fixed right after you started your review). Not sure though. I'm not seeing a failure right now at least. I can look at the CMFPlone failures now. I don't think that has anything to do with your plip but of course it would be great to see these fixed anyway (in case you can confirm them). I've just checked in my comments. http://svn.plone.org/svn/plone/review/plip126-link-redirects/REVIEW-NOTES.txt Raphael Andrew ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #126 ready for review
David Glick wrote: PLIP 126 (Link type should automatically redirect when accessed directly) has been implemented. You can get the review buildout from: http://svn.plone.org/svn/plone/review/plip126-link-redirects I'm going to paste the contents of http://svn.plone.org/svn/plone/review/plip126-link-redirects/PLIP_126_README.txt here for ease of any discussion... Review bundle for PLIP 126: Link type should automatically redirect when accessed directly == As Danny triggered some discussion already I'll add my comments (which I don't consider finished yet - that's why I didn't post them up to now). It's been a while that I did this and I might not be up-to-date with everything. Raphael's comments == (as of 2009-01-16) * on a new site the link type and the configuration options work as advertised * the migration worked for me on a randomly picked site of mine. * I don't understand why 'link_view' isn't made available as an alternative view on instance base still. That could easily be achieved by leaving it in the Available view methods property of the FTI. That way one could control this behavior on instance base even. At the very least this should be properly documented. * running the tests for CMFPlone I get 3 failures but they are all unrelated to the changes in question here (UnicodeSplitter, Latin1 processing, and migration related stuff) * Running the tests of plone.app.controlpanel on a vanilla checkout of the plip buildout generated one failure for me (Ubuntu/packaged uncustomized Python 2.4): ... Set up Products.PloneTestCase.layer.PloneSite in 18.665 seconds. Running: . Failure in test /home/ritz/buildouts/reviewing/plip126-link-redirects/src/plone.app.controlpanel/plone/app/controlpanel/tests/types.txt Failed doctest test for types.txt File /home/ritz/buildouts/reviewing/plip126-link-redirects/src/plone.app.controlpanel/plone/app/controlpanel/tests/types.txt, line 0 -- File /home/ritz/buildouts/reviewing/plip126-link-redirects/src/plone.app.controlpanel/plone/app/controlpanel/tests/types.txt, line 75, in types.txt Failed example: self.browser.contents Expected: '...Globally addable... ...Allow comments... ...Visible in searches... ...input id=redirect_links... ...type=checkbox... ...name=redirect_links:boolean... ...checked=checked... ...label for=redirect_links... ...Redirect links to remote url...' Got: '\n \n\n\n!DOCTYPE html PUBLIC\n -//W3C//DTD XHTML 1.0 Transitional//EN\n http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;\n\n\nhtml xmlns=http://www.w3.org/1999/xhtml; xml:lang=en\n lang=en\n\n (truncated by me here) Guess it's because it expects ...Redirect links to remote url...' but it gets ...Redirect immediately to link target... Potentially more to follow Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #240 ready for review
Erik Rose wrote: I actually first implemented it exactly that way (even called it IRefreshableLockable), then wondered if the complexity was worth it. I can go either way, but would like to hear some other opinions of best practice in a case like this. For what a non-3.x-FWT opinion is worth, I'd rather program against a proper IRefreshableLockable interface. Or, if nobody's implementing it in the wild, it'd be even better (less complex) to revise ILockable. I'd recommend to stay away from revising ILockable as this isn't necessarily even Plone specific. IIRC Jeff and I where trying to follow the at-the-time default way in which Zope handled DAV locks when we wrote this. Raphael Cheers, Erik ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP review deadline has passed - time to review!
Andreas Zeidler wrote: [..] personally i think it'd be stupid to not consider changes that were ready for a while now. i mean, yes technically you missed the deadline, but to me i makes a subtle difference if you the code isn't quite ready yet or if only the notification mail went missing — somehow :). anyway, i'm +1 on considering the bundle. +1 here as well Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #240 ready for review
David Glick wrote: [..] Hey, just wanted to note that Andrew and I investigated this, discovered it was due to a previously existing bug in the unlockOnFormUnload.js script, and implemented a fix in the branch for PLIP #240. In the process we also discovered a related bug which results in items getting unlocked following a validation error even though someone is still editing. We'll port the fix for that issue to the 3.2 branch and trunk regardless of the decision on PLIP 240 as a whole. Great! Obviously this is fine with me as this is just a bug fix. Thanks for looking into this, Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Plone-developers] [Framework-Team] Re: Plone 4 Framework Team Selection List
Wichert Akkerman wrote: Previously Tom Lazar wrote: this is a fundamental change in how the framework team will operate from now on. we're no longer just a group of individuals who quietly need to make some sense of PLIPs and their implementation on their own but more of a clearing house. So, do I understand correctly that the group of people that selected the framework team (which does not include those selected people itself) has also gone one step further and defined a whole new process for how that team will work? As one of the responsible ones for that decision I'll add my view as well. I think we all share Wichert's concerns that UI needs to get more attention - and so does documentation. As has been pointed out already there is an expectation that the way in which the framework team is going to work might change (and I stress this is an expectation by some at this point - no clear cut decisions yet. And yes, that can be criticized.). Rather than having team members with different domains of expertise taking care of different aspects of PLIPs it has been suggested that framework team members act more like editors of a scientific journal meaning they can decide on acceptance if they feel comfortable with the decision but they usually ask for advice from respected players in the field. This can take any form in principle. Here, my expectation is that team members may choose to bring up whatever they think needs to be considered - either on the dev list or by actively approaching someone they trust. They take the responsibility for the decision they make but they don't necessarily do the work of reviewing and evaluating everything themselves. It is still not an easy task as people can fail to address the right issues in the first place but I do have a strong trust in the appointed team that they will do their best also when it comes to UI evaluations and improvements as well as to documentation matters. Sure enough we don't know yet whether this will work as expected but at least I do see a chance that this could even be better than having one or two (usually very busy) UI experts on the team who are expected to look at each and every PLIP with respect to UI issues. Just my 2 cents, Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Close Nominations Soon?
Tom Lazar wrote: On 20.11.2008, at 09:47, Andreas Zeidler wrote: On Nov 19, 2008, at 6:29 PM, Steve McMahon wrote: It looks to me like we're getting a pretty good list of nominations. yes, very good! :) Shall we close nominations in a week? I can send deadline announcements to the lists and news. wasn't that the plan anyway, i.e. close it by the end of the month? anyway, +1 from me! +1 on both of the above from me ;-) +1 here as well Raphael 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/ plone 3.1.7 released! -- http://plone.org/products/plone/ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] 3.3 timeline
Andreas Zeidler wrote: On Nov 6, 2008, at 2:58 PM, Raphael Ritz wrote: So I'd like to reinforce Wicherts call for early submissions. +1. any ideas about how to get developers to actually try to commit their stuff early? xmas presents or something? :) Beer ;-) Raphael 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/ plone 3.1.6 released! -- http://plone.org/products/plone/ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] 3.3 timeline
Andreas Zeidler wrote: danny, raphael, and also steve and jon, would that work for you? that's to say, realistically, like in being able to do all necessary reviews etc on time? :) I hope so. At least I'll try to plan for it to the extend possible. What I can say today already, however, that it should be easiest for me to allocate time over the Holidays - late December/early January that is. So I'd like to reinforce Wicherts call for early submissions. Raphael if not, please tell us now so we can adjust things. we'd really like to stick with the plan this time... cheers, andi On Nov 5, 2008, at 1:36 PM, Wichert Akkerman wrote: The proposal we came up with today at lunch is: The PLIP implementation deadline will be half January, after which the framework team has a two week period to review all PLIPs. This will be followed by a week during which developers can rework their implementation (code, UI or documentation) to solve any problems found by the framework team. The framework team will then have another week during which is will re-evaluate previously rejected PLIPs. That means that half February we will have a final verdict for all PLIPs. In addition people are highly encourages to submit their implementation before the deadline, and the framework team will try to review PLIPs as soon as they are submitted. PLIPs submitted after the deadline will have to wait for 3.4. Steve and Jon will be asked to manage the process and make sure everyone is playing by the rules. Wichert. -- 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.1.6 released! -- http://plone.org/products/plone/ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] 3.3 timeline
Tom Lazar wrote: On 03.11.2008, at 10:27, Wichert Akkerman wrote: I've been told the framework team wants to be involved with setting timeframes for releases. I want to propose to take this one step further during the PLIP handling phase: I would like the framework team to propose a timeline for PLIP implementation and review deadlines. Can the framework team make a proposal this week? perhaps, martijn, andi and myself (3/5ths of the team, afterall...) can jumpstart this with you over lunch day after tomorrow (after andi arrives here in tønsberg)? my idea is that the four of us could discuss a proposal which we then send to the list for approval. Sounds like a plan; have fun in Tønsberg ;-) Raphael (somewhat further East in Scandinavia) cheers, tom 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP Tallies
Steve McMahon wrote: Hi Raphael, Hi Steve, sorry for being late and once more a big thanks to you for taking this on. Here now my votes (note to others: they are not (all) on plone.org; even logging in timed out repeatedly for me - which is one of the reasons I'm late) Votes in parentheses are repetitions from previous statements all others are new (didn't realize until now that we have 17 PLIPs) 126 : +1 187 : +1 197 : +1 228 : (-1/+1) - see comment on site 232 : (+1) 234 : (+1) - see comment on site 236 : -1 237 : (+1) 238 : (+1) 239 : +1 240 : +1 241 : +1 242 : -1 243 : +1 244 : -1 (seems to me we first have to figure out what we really want here) 246 : (+1) 247 : +1 I don't think this will change any decisions made already but for completeness sake. Now on to the real work - the reviewing. How do we distribute that across the team? Raphael If you'll also send me a quick list of your new votes, it will help me update the tallies. Thanks, Steve On Tue, Oct 28, 2008 at 7:08 AM, Andreas Zeidler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Oct 28, 2008, at 11:39 AM, Raphael Ritz wrote: Andreas Zeidler wrote: On Oct 28, 2008, at 9:21 AM, Wichert Akkerman wrote: Previously Steve McMahon wrote: Here are my 3.3 PLIP tallies as of 5:45 2008-10-28 (UTC). These include some unambiguous votes pulled from e-mail messages to the FWT list. Can this be turned into a result? i'd say not yet. i'm aware the deadline has passed, but i'd like to allow a little more time for tom and raphael to vote. and, speaking of it, does anybody know how to contact raphael. i'm not sure he's been reading his mail, I just got back online ... ok, great! could you please add your votes to _all_ PLIP pages asap? http://plone.org/products/plone/releases/3.3 is a good starting point for opening tabs... ;) andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] mailto:[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.1.6 released! -- http://plone.org/products/plone/ ___ Framework-Team mailing list Framework-Team@lists.plone.org mailto:Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Steve McMahon Reid-McMahon, LLC [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 234: Standardizing our use of INavigationRoot
Andreas Zeidler wrote: hi team, afaict PLIP 234[1] was never proposed to the framework team list. technically we require this in order to consider a PLIP, or at least we repeatedly asked PLIP authors to announce their PLIPs here so we're aware of them. seeing that this particular PLIP has already received two votes[3] — probably because wichert (i reckon) has included in in the list for 3.3[2] — and since it's already been proposed in august, i suppose we want to be friendly and make an exception here. right? :) that means, however, that we'll need to collect the missing votes asap, i.e. from raphael and tom. so please try to cast them asap! +1 from me on the updated version after having seen Calvin's response to previous critique. Raphael cheers, andi [1] http://plone.org/products/plone/roadmap/234 [2] http://plone.org/products/plone/releases/3.3 [3] actually there are three now including mine -- 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.1.6 released! -- http://plone.org/products/plone/ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP Tallies
Andreas Zeidler wrote: On Oct 28, 2008, at 9:21 AM, Wichert Akkerman wrote: Previously Steve McMahon wrote: Here are my 3.3 PLIP tallies as of 5:45 2008-10-28 (UTC). These include some unambiguous votes pulled from e-mail messages to the FWT list. Can this be turned into a result? i'd say not yet. i'm aware the deadline has passed, but i'd like to allow a little more time for tom and raphael to vote. and, speaking of it, does anybody know how to contact raphael. i'm not sure he's been reading his mail, I just got back online ... Raphael so i'd like to give him a heads up via phone. if anybody's got a phone number, could you please send it to me (via private mail)? What I would like to have is a list of PLIPs, with for each plip the result (accept/recept) and if the result is a reject a rationale for the rejection. We can then post that list to plone-announce so everyone sees what has been decided and why. +1 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/ plone 3.1.6 released! -- http://plone.org/products/plone/ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 246: View for rendering events as an iCalendar file
Alexander Limi wrote: Hi Framework Team, On behalf of Andreas Zeidler, I'd like to offer up the following PLIP for your consideration for Plone 3.3: http://plone.org/products/plone/roadmap/246 It's a pretty trivial PLIP that adds a new view that is capable of rendering events as an iCalendar file, so people can subscribe to Plone events in various calendaring software like iCal, Google Calendar, Outlook, Sunbird, etc. The view is added to ATContentTypes, and is currently implemented on a branch (and includes tests). PS: Andreas is fully responsible for the implementation here, I'm only helping out by writing a short PLIP for him. +1 Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 237 for Plone 3.3 - Minor i18n upgrades
Hanno Schlichting wrote: Hi. I'd like to propose to accept PLIP 237 - Minor i18n upgrades for Plone 3.3. The full text is at http://plone.org/products/plone/roadmap/237. Short version: Ship PloneLanguageTool 2.1 instead of 2.0 and PlacelessTranslationService 1.5 instead of 1.4 with Plone 3.3. +1 Raphael Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 228: Restore 'Add Item..' menu on all pages
Wichert Akkerman wrote: I guess I'm the first one. I want to propose PLIP 228 for Plone 3.3. I feel that removing the removal of the 'Add Item' dropdown in many places in Plone 3 is a regression in behaviour, and makes adding content a lot more cumbersome. The PLIP has so far only received positive responses from several people. The full PLIP can be found here: http://plone.org/products/plone/roadmap/228 Wichert. In light of recent discussions I'm -1 on changing the default but +1 for a switch in config that allows those who want it to bring it back. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 238: Disable inline editing by default
Wichert Akkerman wrote: I want to propose PLIP 238: Disable inline editing by default Motivation -- I suspect that by now most of us have realized that the current inline editing behaviour in Plone 3 is not very practical. It has two main problems: * it is very easily triggered by default, which causes unwanted edit fields to be opened which have to be manually closed. This happens because many, if not most, people click accidentily, select text to keep track of the reading position, try to select text to copypaste it or for other reasons. Since every single click activates inline edit this happens all too often and becomes very frustrating over time. * as Alexander mentioned in his new UI proposal what you really want is a quick option to go to a full edit-mode. Editing a single field is a much less common operation than we were expecting. I can't think of a single Plone deployment I have been involved in for the last 6 months where we have not disabled inline editing, which strengthens my believe that the current default is wrong. Proposal - Current Plone releases have a simple toggle to enable or disable inline editing. I propose that we change the default for newly created sites to disabled. Please note that I do not propose to disable inline field validation in edit screens: that is a very useful and desirable feature. Wichert. +1 on just changing the default. Raphael PS: And while we are at this: personally I do like inline editing for simple fields like title, description, a date and such. But where I really HATE it is when it comes to text fields as they often contain a large body of text that you want to scroll through, that has links embedded that you want to click etc. But that's not the matter of this PLIP and it seems like we are going to see more on this soon anyway. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Notes from Framework Team Meeting in DC
Tom Lazar wrote: thanks stve for the concise write up. this kind of stuff (i.e. putting consensus into written form) is very important imho. personally, i think your write up (and the decisions we reached during the meeting) strike a very good balance between being too formal and thus restricting on the one hand and too vague (and thus useless) on the other. i would like to suggest that we post your writeup onto the framework team page at plone.org as a first step towards the transparency it itself mentions. any objections? Fine with me. And also from my side a big thanks to Steve! (too bad I couldn't be there ...) Raphael cheers, tom On 20.10.2008, at 00:20, Steve McMahon wrote: Here are my notes from the DC Framework Team meeting. Please discuss anything I've missed, gotten wrong, or stated too absolutely. We'll eventually codify the consensus version somewhere on Plone.Org. Thanks, Steve Mission -- The Framework Team is the gatekeeper for determining which Plone Improvement Proposals (PLIPS) are incorporated into particular versions of Plone. The team recruits release manager candidates and recommends them to the Plone Foundation Board. The team makes recommendations to the release manager for which PLIPS should be incorporated into Plone. Neither the team nor the release manager set the long-term vision for Plone. That is done by the Plone Community. The team is reponsible for taking community opinion and strategic goals into account when considering improvement proposals. The team has an obligation to account to the community for its decisions on Plone features. Framework Team Procedures --- Decisions on procedures and structure are to be made by consensus. The PLIP decision-making process should be transparent to the community. Recruiting discussions may be private. The Framework Team is self-perpetuating. It chooses members for itself and successor teams in consultation with team alumni. Criteria for choice may include a desire for diverse, in-depth experience, and the ability of candidates to work well in concert with existing and other proposed members. The number of members is flexible, and should ideally be odd. The team is not a formal committee of the Plone Foundation, but is expected to coordinate with the foundation board as necessary to achieve its mission. Recommendations to the release manager are made by voting on PLIPs. At least two team members should review every PLIP in depth. Ideally everyone should vote on every PLIP. The team may ask/appoint non-members to assist in secretarial, organizational and communication roles. Plone 3 and 4 --- We anticipate that Plone 3.x will be maintained and improved well into the development of Plone 4.x, and possibly after its release. The 3.x framework team will stay largely intact so long as feature improvements to 3.x are under consideration. The 3.x team will begin by end of month to recruit for a 4.x team. A call will be made to the community asking for applications. The 4.x team should be in place by January 30th, and one of its first acts should be to recommend a 4.x release manager to the board. Jon Stahl, Geir Bækholt, Steve McMahon and Matt Bowen have all volunteered to provide organizational, secretarial and communication assistance for the teams. -- Steve McMahon Reid-McMahon, LLC [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 244: Portlet management improvements
Martin Aspeli wrote: Hi all, Ricardo Alves has been working (with me providing some guidance) on some incremental improvements to plone.app.portlets. We'd like to propose this for Plone 3.3: http://plone.org/products/plone/roadmap/244 +1 on the topic as such. But as Wichert and Alex have pointed out the control of blocking/inheriting might need some further discussion to figure out how to get it right. I too would prefer if we wouldn't introduce too many different ways to effectively do the same things over time just because the first attempt falls short in some way. To Jon's remark: of course this would be a great feature and if Ricardo and Martin could get that supported this would be truly great. But let's consider what we have now first. There will always be room for improvements. Raphael The key suggestions are: - Create a site wide portlet category for portlets that should show on all pages (unless blocked). Currently, people have to use contextual portlets at the root of the site for this, which gets cumbersome since if you block them in one folder, you need to re-add all portlets in subfolders. - Improve the contextual manage portlets screen so that you can see what portlets will disappear/appear when you block/unblock. - Add a setting (actually, an annotation) to each individual portlet assignment that determines whether it is shown in subfolders or not. This will probably need to default to true, at least for migrated sites, but may be better off as defaulting to false. This will solve the problem of I want this portlet in this folder, but not all sub-folders. Currently, you need to go and block contextual portlets in each sub-folder, which is a pain. Each of these could be implemented separately, although they do go hand in hand. Cheers, Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] What is Plone 3.3?
Martin Aspeli wrote: Hi, Hi Martin, I hear you loud and clearly ;-) Actually I even share all of you concerns. And I was just about to propose the add-on approach while reading your message. I would agree that if we are providing such changes in the 3.x series site admins should be able to decide what they want (and some things wouldn't even need add-ons like the moving of the 'manage-portets' link: adding an invisible site action and giving the link a dedicated CSS class should make it pretty straight-forward for people who want that change *if* it is properly documented). In particular the printed books are a strong argument from my POV. Just imagine a brand new book coming out in a few weeks from now and parts of it are already outdated. That wouldn't fit my understanding of what we want 3.x to be. Raphael Over the past three days of conference chatter, we've been talking a lot about how we're proud of Plone 3.x being boring. It's stable. Upgrading is safe. Improvements are incremental. You and your users don't need to re-learn lots of things when moving from one 3.x version to another. Now, several PLIPs are being proposed for 3.3 that I feel would break this mantra. They are not accepted yet, obviously, but I think it's important to be explicit about our intentions. *If* we agree that we want to retain stability and predictability across the 3.x series, then we have to accept that: - We can't remove, change or move major pieces of the UI. - We can't break add-on products and (sane) customisations. This means that we sometimes have to delay perfecting things until at least a new major release. There are books in print (and about to go to print) about Plone 3. There is documentation on plone.org that we can't (and shouldn't) just change. People have received training and spent time learning how to use Plone. If the UI changes, they have to be re-trained. Just moving a link may not seem like much, but I guarantee you that it will cause a lot of pain and frustration. Right now, the things that concern me are: - Adding a new way to add content (the add sibling proposal) - Moving the contextual manage portlets link somewhere else - Removing the display menu and putting the behaviour on the fieldset (the last one is doubly bad, because it would require any add-on product that used this menu to be updated in a possibly backwards-incompatible way, to add a field to replicate this, and we'd need a unique solution for non-AT content). Note that I actually agree with all these changes: The display menu causes confusion; the manage portlets link is ugly; adding a sibling object is too cumbersome. However, we should solve these problems properly in the context of Plone 4, not make tactical changes in 3.x that cause confusion and break documentation. Luckily, there's a workaround. :) All of these changes could be provided with easy-to-install add-on products. These could be tested on real users and used by those who want different behaviour. Cheers, Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 242: Move manage-portlets link to site actions
Wichert Akkerman wrote: I'm too late for my own deadline, so I have no expectation that the framework can review this on time time. If you guys have a bit of spare time I would appreciate it though :) Hi Wichert, don't worry too much. At least I planned to start reviewing only after the conference sprints. I want to propose PLIP 242 for Plone 3.3: Move manage-portlets link to site actions. While I think I see your point I'm not sure it's the right place to move it to. First, I agree that the current situation isn't perfect. But: those assignments are context depended and site actions are typically used for (site) global settings. Now while you can always link to the right URL, of course, I'm not sure that that would be less confusing. From this POV the document actions might be more appropriate, don't know. Or some new, location specific management category could be introduced which could also be home for some of the things we currently put on the edit form for lack of a better place (like 'exclude from navigation' to give one example). What do others think? Raphael Motivation == Both portlet columns feature a manage portlets link at the bottom. This has several problems: * the location of the link and the fact that each column has its own manage portlet link leads users to believe that that link will go to a page to configure that specific column, which is not true. * Many (if not most)l custom themes style the portlet column and have no room for the manage portlets-link below the portlets. * all configuration options are in site or document actions, except for manage portlets- a needless inconsistency. Proposal Remove the manage portlets-link from the default portlet renderer template and replace it with a site action. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 323: Resource Registries Improvements
Wichert Akkerman wrote: A PLIP from Michael Dunlap and Florian Schulze which is marked as being propsed in its workflow state but apparently not mailed to this list (I sense we need a content rule for this stuff..) after the upgrade to Plone 3 ;-) (and once the trigger on workflow state changes works reliably again) http://plone.org/products/plone/roadmap/232 Allow Resource Registries to use conditional comments for CSS to bring the IEFixes.css into the registry and allow external references to resources for all registries. I think we have this on the radar already (seeing comments from most team members on the plip page) Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Framework Team Meeting at Conference
Steve McMahon wrote: Am I right that Raphael isn't going to be at the conference? No, unfortunately not (for various reasons though I'd love to come ...). Raphael PS: don't worry too much about the jet lag Steve. The first evening(s) are easy. It's the third or forth that are getting tough in my experience ;-) If so, have we now heard from everyone attending? It looks like everyone will be there Monday-Sunday. Would an evening before the conference be good? I know Martin is teaching, and might be tired. But, If that works, it could just be a dinner together. If that sounds good, would Tuesday night be best? I assume that there will be lingering jet lag on Monday. Thanks, Steve On Sat, Sep 6, 2008 at 5:47 AM, Andreas Zeidler [EMAIL PROTECTED] wrote: On Sep 4, 2008, at 5:03 PM, Steve McMahon wrote: Can we start by finding out when folks are arriving in and leaving DC? i'll be there from monday 6th until monday 13th. thanks steve for keep bringing this up! :) 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/ plone 3.1.5.1 released! -- http://plone.org/products/plone/ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Framework Team Page Needs Updating
Alexander Limi wrote: On Mon, 18 Aug 2008 12:35:35 -0700, Martijn Pieters [EMAIL PROTECTED] wrote: In your specific case, that'd be for Plone 3.3. Current Plone trunk will be version 4.0. I'd keep it on the list and not canvas us directly though. His point still stands — the team list is outdated. Why do you think so? To me, this looks just fine. Raphael PS: maybe it's about time to think about a new team for Plone 4 (or Plone 3.3 even) though. If you send me a list of the missing members, I'm happy to update the group. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Resource Registries improvements PLIP
Michael Dunlap wrote: Hello framework-team! I have a PLIP ( http://plone.org/products/plone/roadmap/232) that details two potential changes to Resource Registries that would allow for 1) Conditional Comments for CSS Resources, and 2) support for external resources (http://example.com/myresource.js ) for example. I submit it for your consideration. -Michael Dunlap +1 from me on both changes. Raphael /finally back online after the summer ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Framework Team Meeting in DC
Wichert Akkerman wrote: Previously Tom Lazar wrote: steve, that's an excellent idea! can we do a quick 'show of hands' here on the list, which framework team meamber will be (if at all) when in DC? like so, perhaps? | from | til - tomster | 6th | 12th witsch | 6th | 12th wiggy | | raphael | | danny | | martijn | | I won't be in DC. Me neither - unfortunately :-( Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] availability over the next 5 months
Wichert Akkerman schrieb: Can the members of the framework team mail me some information on their availability for the next couple of months? If there are periods of a week or longer that you know you will not be able to dedicate enough time to framework team business I'ld like to know so I can take it into account when planning the next release(s). I'll be on intermittend connectiviy until late July/early August. After that, things should be normal again (aka dependend on day job and family ;-) ). Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: 3.2 Release Manager
Martijn Pieters wrote: On Wed, Jun 25, 2008 at 9:43 AM, Martin Aspeli [EMAIL PROTECTED] wrote: As far as I know I'm still release manager for 3.x. I've been waiting for the foundation board (in the person of that same limi) to answer some questions I asked about the release manager stipend. Once those have been answered I'll start planning a 3.2 release. I'm really glad Spanky's showing so much enthusiasm and willingness to do an important job. That said, I think there is a lot to be said for having the same release manager for the whole 3.x cycle, from a continuity and stability perspective. I must say that I agree with that sentiment, especially in light of what a great job Wichert has done so far. I'm in favour of not changing a winning formula. ;-) I'm probably missing something but I was quite surprised by this discussion coming up now. I would also very much prefer Wichert to continue for the Plone 3.x line if at all possible. Maybe there is a way for Spanky to get on board for Plone 4 by helping Wichert and thereby being trained on the job? @Spanky: please don't get this wrong. I very much appreciate your willingness to take on such an important task. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] The final(?) verdict
Tom Lazar wrote: On Feb 20, 2008, at 9:45 PM, Danny Bloemendaal wrote: [..] I'd say to just clear the message when it is no longer needed and indeed show the message if pressing the save button resulst in an error. That means that no message is shown during inline validation. If the message is cleared because inline validate caused all the error solved then that is ok. It would still be good though to have a more smooth disappearance of this. (When do we finally start using smooth transitions in plone???) perhaps as soon as 3.1 ;-) remember, we will have the full power of jquery at our hands. adding a smooth transition for disappearing the status message will be trivial, once florian has merge #212... good thinking, though. this is really a clear case when animation really serves a purpose and isn't just eye candy! I like the idea. BTW, I just removed the generation of portal status messages triggered by inline validation but I left the clearing part in place for now. http://dev.plone.org/plone/changeset/19421 Raphael hth, tom . At least you get rid of the sudden jumping and your eye can follow the current widget that has the focus. Danny. ___ 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 wrote: [..] even though i just spent another two or so hours reading up and sorting out tickets, this is still valid. i guess the first task is pretty much done, or at least the status and assignments[1] of all tickets should reflect the current status. the counting and reporting to wichert still has to be done, so someone needs to step up here!! Done. See my recent post to the list earlier today http://lists.plone.org/pipermail/framework-team/2008-February/001960.html (I didn't change any ticket status though) Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] The final(?) verdict
Martin Aspeli wrote: [..] PLIP #202: Support inline validation and editing for formlib forms http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7737 +4 - but there is still some debate about what's the best way to handle the portal status message. Once this is sorted out (and implemented) it's ready for merge I agree with Danny that that must be fixed before merge. Do we have consensus here? IMHO, the portal message should just not be shown. It's not shown for AT edit forms as far as I recall. I'm happy to do whatever, though. As I feel kind of guilty here I try once more to explain my point of view. In Martin's original implementation the portal status message was left alone - which is what Danny is proposing also if I understand him correctly - but that reveals the following issue: Take the sample form shipped with the review buildout and just submit the form without entering anything (by pressing 'save' that is). You will get a portal status message Error: ... *and* the fields will be highlighted as usual. Now go and enter valid input. The fields will turn normal as you switch focus but the error message in the portal status message stays around resulting in a view of the form where there is an error message at the top of the page but no errors present. This is what I found confusing and why I introduced updating the portal status message from the inline validation as well. I agree that this has a negative impact on user experience as things start to jump around because of the portal status message changing but still I consider providing contradicting feedback to the user as we had it initially to be even worse. I don't know the solution to this myself and I would be happy to see this addressed the right way if somebody knows what the right way would be ;-) Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] The final(?) verdict
Tom Lazar wrote: Hi Tom, maybe i didn't understand you correctly, but i was under the impression that you had additionally suggestded that the inline validation should als explicitly *clear* and statusmessages. this would certainly address the issue you're mentioning below... at least i think so. *scratches head* Yes, it does. That's why I had introduced it in the first place. But this also has the unwanted side effect that things start jumping up and down whenever the portal status message gets inserted or removed. This is annoying and therefore it is suggested to leave the portal status message alone. But this would be exactly what Martin submitted in the first place where I stumbled across the issue I'm trying to raise (but seem to be unable to describe - I wish it were a five minute thing to do a screen cast ...) http://dev.plone.org/plone/changeset/19239 shows the changes I introduced: Line 66/67 issue a status message in case of an error occurring while 71/72 clear the message on error removal. Prior to that change the portal status message was left alone. Now, a variant that we might want to consider is only to clear (but not to issue the error in) the status message. That would address the specific concern I have about inconsistent feedback and make things jump around a bit less. Still not sure what's the right thing to do here though Raphael just my $0.02, tom On 20.02.2008, at 13:28, Raphael Ritz wrote: Martin Aspeli wrote: [..] PLIP #202: Support inline validation and editing for formlib forms http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7737 +4 - but there is still some debate about what's the best way to handle the portal status message. Once this is sorted out (and implemented) it's ready for merge I agree with Danny that that must be fixed before merge. Do we have consensus here? IMHO, the portal message should just not be shown. It's not shown for AT edit forms as far as I recall. I'm happy to do whatever, though. As I feel kind of guilty here I try once more to explain my point of view. In Martin's original implementation the portal status message was left alone - which is what Danny is proposing also if I understand him correctly - but that reveals the following issue: Take the sample form shipped with the review buildout and just submit the form without entering anything (by pressing 'save' that is). You will get a portal status message Error: ... *and* the fields will be highlighted as usual. Now go and enter valid input. The fields will turn normal as you switch focus but the error message in the portal status message stays around resulting in a view of the form where there is an error message at the top of the page but no errors present. This is what I found confusing and why I introduced updating the portal status message from the inline validation as well. I agree that this has a negative impact on user experience as things start to jump around because of the portal status message changing but still I consider providing contradicting feedback to the user as we had it initially to be even worse. I don't know the solution to this myself and I would be happy to see this addressed the right way if somebody knows what the right way would be ;-) Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] The final(?) verdict
Andreas Zeidler wrote: [..] PLIP #216: Template overrides http://plone.org/products/plone/roadmap/216 https://dev.plone.org/plone/ticket/7750 -4 - never submitted (Raphael notes: not sure we are on trac here as all this is about is to include the z3c.jbot package from http://svn.zope.de/zope.org/z3c.jbot OTOH people who want that can just do it) well, i guess first of all the fact that no bundle was officially submitted means that the code hasn't been reviewed either. so i don't think we can include it into the distribution just like that. however, that's just a policy issue, not a technical one. on the technical side, however, i think we shouldn't just include more and more ways of customizing plone. people, i.e. developers and integrators, are already confused more than they should be. so what we really should do is think about better ways to integrate something like jbot with customerize and the old customization story to make the whole customization story more consistent. so imo this could very well go into 3.2, but more as some part of a bigger effort in that area. in short: i like the idea, but i'm -1 on including this _now_. Note that I said -4 - never submitted. My remark was triggered by looking at http://plone.org/products/plone/roadmap/216 and realizing that we were all positive on this in principle and then I started wondering whether that could have been interpreted as acceptance already because in contrast to most other PLIPs there is hardly any implementation involved (for the minimal solution at least). But I agree with everything you said above and I know some of us have been discussing this also at the summit and obviously we need a better and more streamlined customization story where jbot might be part of the solution but definitively not the only one. Considering that all our conversations here are archived and discoverable by search later on I thought in include PLIPs that were initially considered even though they finally never got submitted in the overview as well as adding comments where I deemed appropriate. This was not meant to question our current judgment though I now realize that I phrased it as such. Well, it can be tough at times to deal with such issues in a (for me and I know for many of us as well) foreign language after all :-( Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] The final(?) verdict
Hi Folks, at Wichert's request and in order to update us all I've just compiled the following overview. I hope I didn't forget anything. Feel free to comment on this as you see fit. I've scanned the tracker and looked again at some of the PLIP pages but I didn't dig through the mailing list archive. == Plone 3.1 PLIP status report as of 2008-02-20 (4am CET): PLIP #187: Working Out-of-the-box WebDAV http://plone.org/products/plone/roadmap/187 https://dev.plone.org/plone/ticket/7732 +3 - ready for merge PLIP #195: Support product dependencies http://plone.org/products/plone/roadmap/195 https://dev.plone.org/plone/ticket/7733 +4 - ready for merge PLIP #196: GRUF removal http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7734 -4 - not submitted PLIP #200: Kupu formlib widget http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7735 +3 - ready for merge PLIP #201: Improve the UberSelectionWidget UI http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7736 Don't know, seems to me this might be deferred to 3.2 It does seem to look good already though. At those who looked more closely at it: what do you really recommend by now? PLIP #202: Support inline validation and editing for formlib forms http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7737 +4 - but there is still some debate about what's the best way to handle the portal status message. Once this is sorted out (and implemented) it's ready for merge PLIP #203: Manage portlet assignments with GenericSetup http://plone.org/products/plone/roadmap/203 https://dev.plone.org/plone/ticket/7738 +3 - but before merge the encoding issue should be fixed (Martin might look at this later today) PLIP #204: Manage content rules using GenericSetup http://plone.org/products/plone/roadmap/204 https://dev.plone.org/plone/ticket/7739 +3 - but before merge the encoding issue should be fixed (Martin might look at this later today) PLIP #205: Flexibility Associating Portlet Types and Portlet Managers http://plone.org/products/plone/roadmap/205 https://dev.plone.org/plone/ticket/7740 +3 - ready for merge PLIP #207: Allow Custom Portlet Managers http://plone.org/products/plone/roadmap/207 https://dev.plone.org/plone/ticket/7741 +2 - ready for merge PLIP #208: Adapter-Based Local Role Lookup http://plone.org/products/plone/roadmap/208 https://dev.plone.org/plone/ticket/7743 +2 provided alec adds the migration step as promised PLIP #209: Add buildout to Unified Installer http://plone.org/products/plone/roadmap/209 https://dev.plone.org/plone/ticket/7744 +3 ready for merge but just so we don't forget: after merge we should again double-check that we don't give wrong advice to people about where to put add-on products in the file system in the Plone add-on products config panel (and maybe make it more obvious how to install eggs) PLIP #210: Improve UI support for objects on multiple workflows http://plone.org/products/plone/roadmap/210 https://dev.plone.org/plone/ticket/7745 -4 - not submitted PLIP #211: Enable dashboard to be locked down http://plone.org/products/plone/roadmap/211 https://dev.plone.org/plone/ticket/7746 -4 - not submitted PLIP #212: Use jQuery Javascript Library http://plone.org/products/plone/roadmap/212 https://dev.plone.org/plone/ticket/7747 +3 - but it seems there are a few little glitches still that may need some attention check back with danny and martijn before merging PLIP #213: Prepare for better Syndication http://plone.org/products/plone/roadmap/213 https://dev.plone.org/plone/ticket/7748 +3 - ready for merge PLIP #215: Include new KSS versions http://plone.org/products/plone/roadmap/215 https://dev.plone.org/plone/ticket/7749 +3 - in principle OK but it seems there are some minor issues that need to be fixed still check back with Balasz before merging PLIP #216: Template overrides http://plone.org/products/plone/roadmap/216 https://dev.plone.org/plone/ticket/7750 -4 - never submitted (Raphael notes: not sure we are on trac here as all this is about is to include the z3c.jbot package from http://svn.zope.de/zope.org/z3c.jbot OTOH people who want that can just do it) PLIP #217: Use Adaptation for Workflow Assignment http://plone.org/products/plone/roadmap/217 https://dev.plone.org/plone/ticket/7751 +2 - ready for merge PLIP #218: Increase Restrictions, and Ability to Change, Addable Portlet Types by Interface http://plone.org/products/plone/roadmap/218 https://dev.plone.org/plone/ticket/7752 +3 - ready for merge PLIP #219: New site search implementation http://plone.org/products/plone/roadmap/219 https://dev.plone.org/plone/ticket/7753 -4 - not submitted PLIP #220: Improve browser layer support http://plone.org/products/plone/roadmap/220 https://dev.plone.org/plone/ticket/7754 +2 - ready for
[Framework-Team] comments on plip187: WebDAV
Hi, here my current take on this PLIP: tested on Linux/Ubuntu 7.10 with Nautilus and Cadaver as WebDAV clients. First, my overall impression: I'm somewhat at a loss here as I don't know what to expect and therefore I don't know what to recommend. :-( While all changes introduced are worthwhile improvements (and could go into Plone core as far as I can see) I'm hesitant calling this Working Out-of-the-box WebDAV I think my problem is: what does working WebDAV mean? Examples: (i) Binary fields: when editing a News Item via webdav I don't see how I could manage the image that can be included with an item (nor its caption) (ii) Folders: When copying over (downloading) the default news folder I get a series of error messages from the aggregator topic's criteria (not too surprising) but no news items at all (and of course I've created a few in there before). More generally, folderish items seem to be problematic still. (iii) Extensibility: all marshallers don't seem to delegate the serialization of field values to the fields but rather apply some heuristics to the value. While the current implementations work for field types shipped with AT it is limiting when it comes to supporting custom field/data types. (e.g., my Record- and RecordsField (dict and list of dict types) are not treated correctly neither can I easily hook in my own serializations. I guess other complex field types like the ArrayField, the DataGridField, the CompoundField, etc. might have the same problem.) Recommendation: as I think any improvements on the WebDAV side are worth it I'm generally positive but I would be hesitant advertising it too boldly (WebDAV is maybe just too broken in general?). I know this doesn't really help us and I probably should have brought this up earlier but maybe others looked at this as well or have opinions on the issues I raised. Sidnei, want to chime in here? Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] comments on plip224-csrf-protection
Hello again, I have nothing to add to Andi's excellent review. I only want to reinforce that we should not only ship with the two new packages but also start using them right away. At least for security and administration related things like: the personalize_form, password_form, ownership_form, the @@sharing view, the control panel forms (which are quite a few) and maybe 'base_edit' or 'atct_edit' simply because it is used so much. What I still don't see is whether anything KSS related needs attention here as well. It wouldn't hurt either to make the plone.app.protect README available from the prefs_install_products_form (maybe QI should grow the ability to look up the README from eggs in general?) simply to make it easier for people to figure out what's going on and more importantly how they are considered to use this in their own stuff. Summary: +1 on inclusion of the packages but improvements along the lines mentioned above very welcome. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: comments on plip187: WebDAV
Sidnei da Silva wrote: Hi Raphael, Hi Sidnei, first of all thanks for your prompt reply! While the points you raised are valid, I don't see anything that disqualifies this PLIP. More below. I'm also going to comment inline below ... Your points will certainly be considered for possible improvements after the PLIP is merged. In fact, some of them are already on my TODO. On Feb 18, 2008 5:09 AM, Raphael Ritz [EMAIL PROTECTED] wrote: Hi, here my current take on this PLIP: tested on Linux/Ubuntu 7.10 with Nautilus and Cadaver as WebDAV clients. First, my overall impression: I'm somewhat at a loss here as I don't know what to expect and therefore I don't know what to recommend. :-( While all changes introduced are worthwhile improvements (and could go into Plone core as far as I can see) I'm hesitant calling this Working Out-of-the-box WebDAV I think my problem is: what does working WebDAV mean? Examples: (i) Binary fields: when editing a News Item via webdav I don't see how I could manage the image that can be included with an item (nor its caption) That wasn't a stated goal of this PLIP. OK, fair enough. (ii) Folders: When copying over (downloading) the default news folder I get a series of error messages from the aggregator topic's criteria (not too surprising) but no news items at all (and of course I've created a few in there before). More generally, folderish items seem to be problematic still. The 'news folder' is not a folder, is a 'smart folder'. It does (should?) not contain files, but basically presents a search result. As such, it is hard to decide what should happen there, and I'm open for suggestions. No, it's a bit trickier than that: In current Plone 3 the news folder is an ATBTreeFolder which contains a topic as default view. It is perfectly fine (and actually supported through the default Plone UI) to add news items to this folder. The problem I was having is that when trying to download the *folder* I didn't get the news items contained in there probably because of the errors triggered by the contained topic. See what mean now? We could either: - Display the 'contents' of a 'smart folder' and allow for downloading them. The problem might be that since they are not directly contained inside that 'smart folder', maybe some WebDAV clients will complain that the URLs for those items are not 'contained in' the parent. - Serialize the criteria for the 'smart folder', and display it as non-folderish. that seems to make most sense to me at the moment Another issue is, when you upload a file to a 'smart folder', where should this file end up? I'm not sure we should even try this. (iii) Extensibility: all marshallers don't seem to delegate the serialization of field values to the fields but rather apply some heuristics to the value. While the current implementations work for field types shipped with AT it is limiting when it comes to supporting custom field/data types. (e.g., my Record- and RecordsField (dict and list of dict types) are not treated correctly neither can I easily hook in my own serializations. I guess other complex field types like the ArrayField, the DataGridField, the CompoundField, etc. might have the same problem.) I did not design the marshalling layer on AT, though I contributed many improvements to it. It is completely possible to create a marshaller that delegates to each field. That's kind of the point I was trying to make: it would certainly be possible (and not that hard even). I don't see how your comment qualifies here though, as we don't ship Plone with any of those different kinds of fields. While you are right in the strict sense I do propose to take a broader look at this. And from my perspective things could be better here. People often don't draw the fine line between Plone the product (as it comes OOTB) and Plone the platform/framework/whatever you call it. Moreover, my view (and certainly Alex's) on Working out-of-the-box WebDAV I guess this is what I'm most worried about: Calling this Working out-of-the-box WebDAV Maybe I'm the only one who has these strange expectations but for issues like the ones mentioned above I feel uncomfortable with advertising it as such. is: you drag a file in, and you get a file (preferably the same file) out. The previous status-quo, which *tried* to serialize each field individually could be interesting to geeky types who know what they are doing, but is totally useless as there are no known editors (other than text editors) that could edit those files. Recommendation: as I think any improvements on the WebDAV side are worth it I'm generally positive but I would be hesitant advertising it too boldly (WebDAV is maybe just too broken in general?). It is certainly not too broken, OK, maybe my expectations are somewhat broken then. and it's a great improvement over what we had before. Didn't I say so as well
Re: [Framework-Team] Testing for PLIP 209: Unified Installer Plus Buildout
Tom Lazar wrote: i just realized, that steve might not get notifications from trac, so i hereby post my previous comment: Hi, after checking out : checking out what? As Steve said, you should download the tarball. and issueing the following command: sudo sh install.sh --target=/opt/zope/instances/209 --user=tomster --instance=plip209 zeo i get the following output: I just tried this on my box (Linux/Ubuntu 7.10) and it just worked. With other words: I cannot reproduce the issue you are seeing. Raphael ZEO Cluster Install selected Detailed installation log being written to /opt/zope/instances/plip209installer/install.log This install script must be run within the installer's top directory. That directory should contain packages and helper_scripts subdirectories. however, i am issuing that command from within the toplevel directory. the log file is empty except for these two lines: Detailed installation log Starting at Fr 15 Feb 2008 16:17:24 CET since nobody else (i.e. martijn and raphael) has reported this, i either have found some bug (unlikely) or (more likely) other folks will overlook the same thing I overlooked... ;-) either way something (probably the README) would need to be clarified. On Feb 16, 2008, at 12:26 AM, Steve McMahon wrote: On 2/14/08, Raphael Ritz [EMAIL PROTECTED] wrote: ... (ii) maybe I screwed it up myself but I couldn't specify a relative path when specifying the target as follows: Thanks! Fixed in svn. __ Steve McMahon Reid-McMahon, LLC [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] my review status
Tom Lazar wrote: On Feb 18, 2008, at 12:56 AM, Andreas Zeidler wrote: On Feb 17, 2008, at 3:21 PM, Tom Lazar wrote: sorry for the delay, i went out with hannosch and lurker yesterday evening, instead of finishing my last review ;-) way to go. i finished 201 but still couldn't get 209 to work (despite the hint from graham) since 209 has already been reviewed twice, i think it'd be sufficient to resolve the issue you were describing. other than that there's probably no need to dig deeper here... that sounds reasonable and as long as the issue does get resolved i'm ready to vote 209 in based on the existing reviews. Just to mention this here as well: I cannot reproduce the issue you are seeing. Are you sure you used the tarball and not a svn checkout? Raphael now what? like i said, imho we should still get secondary reviews for at least 187 and 215. seeing that you've done only six reviews so far (out of the required 7.2), could you please still review 187? wichert's extended the deadline until monday night, so there should be enough time left... sure thing, i'll review 187 during the day and post back. cheers, tom 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/ plone 3.0.5 released! -- http://plone.org/products/plone ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Testing for PLIP 209: Unified Installer Plus Buildout
Steve McMahon wrote:
Thanks for the great review and suggestions, Martijn!
I'm pleased to report that the PID problem is taken care of. Nouri
fixed it for zope2instance in:
http://dev.plone.org/collective/changeset/55898
and for zope2zeoserver in:
http://dev.plone.org/collective/changeset/55899
The other CLIENT_HOME problems are messier than they should be, but
should be taken care of by the
command =
...
find ${buildout:directory} -type d -name var -exec chown -R
${client1:effective-user} \{\} \;
section of buildout.cfg that's inserted for root-mode installs.
Excellent news. Almost +1 on all of this from me as well
but (there's always a but, isn't it ;-) there is one issue
I currently consider a show-stopper (sorry, but it should
be easy to fix as you'll see):
When going to the 'prefs_install_products_form' of a
Plone site it says:
To make new products show up here, put them in the directory
*/tmp/test_PloneUI/Plone-3.0.5-UnifiedInstallerBuildout/zinstance/parts/instance/Products*
on the file system, and restart the server process.
The problem here is that we point people to *parts/instance/Products*
which is plain wrong! Update your buildout and your add-ons will be
gone. :-(
This should rather point to zinstance/products instead.
Apart from that I've only two suggestions for eventually
improving the already excellent documentation:
(i) when describing start/stop/status we might want to add
'fg' (foreground) as a simple means to start in debug mode
without changing the configuration
(ii) maybe I screwed it up myself but I couldn't specify a
relative path when specifying the target as follows:
[EMAIL PROTECTED]:/tmp/test_PloneUI/Plone-3.0.5-UnifiedInstallerBuildout$
./install.sh --target=. standalone
Stand-Alone Zope Instance selected
Detailed installation log being written to
/tmp/test_PloneUI/Plone-3.0.5-UnifiedInstallerBuildout/install.log
Rootless install method chosen. Will install for use by system user ritz
zlib installation: no
libjpeg installation: no
Installing Plone 3.0.5 + Buildout at .
Skipping zlib compile and install
Skipping libjpeg compile/install
Installing Python 2.4.4. This takes a while...
Install of Python 2.4.4 has failed.
Installation has failed.
See the detailed installation log at
/tmp/test_PloneUI/Plone-3.0.5-UnifiedInstallerBuildout/install.log
to determine the cause.
(end of transcript)
Specifying an absolute path, however, worked like a brise.
Should there be a issue hidden here this could be fixed
or mentioned.
Anyway, this is all excellent work. I'm all for adopting
it as soon as possible (although I consider this quite
a drastic change for a x.1 release). But please fix the
wrong pointer in the 'prefs_install_products_form'.
Cheers,
Raphael
Ideally, though, we should work towards a setup where the server and
client processes never write into parts.
Thanks, Steve
On 2/10/08, Martijn Pieters [EMAIL PROTECTED] wrote:
On Jan 17, 2008 2:00 AM, Steve McMahon [EMAIL PROTECTED] wrote:
An implementation of PLIP 209: Unified Installer Plus Buildout is
available for testing at:
https://launchpad.net/plone/3.0/3.0.5/+download/Plone-3.0.5-UnifiedInstallerBuildout-beta1.tar.gz
You have since created a beta2:
https://launchpad.net/plone/3.0/3.0.5/+download/Plone-3.0.5-UnifiedInstallerBuildout-beta2.tar.gz
:-)
As there is no review bundle possible for this, I'll give my review
notes in this reply:
I tested the full download and tested the different installation
options on both Mac OS X and Linux (Debian Etch). Everything worked
absolutely beautifully. In short, my verdict can be summed up as
'absolutely ruddy brilliant!'. I am very impressed with the execution
and the polish on the buildout-version of the unified installer, and
I'll certainly be reusing the precompile recipe in production
buildouts.
One remark about the as-root install using the effective user setup.
There is a problem with that setup which lies outside of the scope of
the Unified Installer, but which will perhaps come up in support
requests. Currently, zope2instance sets CLIENT_HOME as
$INSTANCE_HOME/var, which means on that this variable points to a
subdirectory of the part directory (usually parts/instance). This
means that this directory will get wiped and re-created when updating
the buildout settings for that recipe.
That wouldn't be so big a problem if it weren't for the fact that
various things get written to the CLIENT_HOME, such as the zopectl
daemon PID (at least at some point, it may be that Florian Schulze has
fixed that one). Any files written there are of course written by the
effective user, meaning that a buildout update can perhaps not delete
these files, and/or that the effective user cannot write in the
directory afterwards.
The solution is to create subdirectories of the buildout var/
directory (where filestorage and log live) for each Zope client and
for a zeo server, and setting these directories as the
Re: [Framework-Team] Re: Review process: suggestions, and an offer
Graham Perrin wrote: [..] High quality improvements to Plone, and actions from (for example) the Summit, are to me far more satisfying than a fixed schedule for upgrading. Glad you see it this way ;-) And to add to the general theme (process): At least in my case it wasn't about lack of process or tools. I was always fully aware that I'd promised to review bundles x, y, z until d but I didn't get to all of it. Maybe not too surprisingly things took longer than expected so the time that I did have scheduled and used for the reviewing was too short. You could say now that I was not supposed to look too deeply into the issues I had encountered (even fixing some myself) but when you are at it anyway ... Just my 2 cents, Raphael Regards Graham ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] note on optilude-plip202
This is about kss inline validation of formlib fields. Functionally, it works as advertised but there's a little issue with the feedback to the user as the portal status message can get out of sync. For more see http://dev.plone.org/plone/changeset/19238 and for the implementation of the suggested fix http://dev.plone.org/plone/changeset/19239 As I said: maybe this is too naive still but I think it's at least better than before. @Martin: if you agree with this could you please update the currently failing test? Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] note on plip220-browserlayer
Raphael, 2008-02-12: nothing to add to Andi's comments; +1 from me as well On the cosmetic side I'd like to see the following warnings disappear: /home/ritz/.buildout/zope/Zope-2.10.5-final/lib/python/zope/configuration/fields.py:417: UserWarning: You did not specify an i18n translation domain for the 'description' field in /home/ritz/.buildout/eggs/plone.browserlayer-1.0rc2-py2.4.egg/plone/browserlayer/tests/testing.zcml warnings.warn( /home/ritz/.buildout/zope/Zope-2.10.5-final/lib/python/zope/configuration/fields.py:417: UserWarning: You did not specify an i18n translation domain for the 'title' field in /home/ritz/.buildout/eggs/plone.browserlayer-1.0rc2-py2.4.egg/plone/browserlayer/tests/testing.zcml warnings.warn( like so (sorry, I'm offline and don't have a checkout of this at the moment) [EMAIL PROTECTED]:~/.buildout/eggs/plone.browserlayer-1.0rc2-py2.4.egg/plone/browserlayer/tests$ diff testing.zcml testing.zcml~ 4,5c4 xmlns:genericsetup=http://namespaces.zope.org/genericsetup; i18n_domain=plone --- xmlns:genericsetup=http://namespaces.zope.org/genericsetup; (wrote this on the flight back from the summit the other day) Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 224: CSRF protection framework
Wichert Akkerman wrote: See http://plone.org/products/plone/roadmap/224 for details. I absolutely hate to do this since it violates our process and we already have a large number of PLIPs waiting for review, but I am proposing this PLIP for Plone 3.1. Anarchist as I am I have no problem personally with exceptions ;-) The reason I am willing to do this is that it improves the security of Plone: it adds protection against the unfortunately quite common CSRF type of attacks. The implementation is based on a long debate we had in the security team recently as a result of a discussion with a security researcher contacting us about possible Plone security issues. I've been sort of following your recent checkins on the issue and while I'm no technical expert on the matter I do agree that this warrants an exception. Sort of like Security first. At this moment I do not have a review bundle ready; I'm hoping that someone will beat me to it since I have very little time to work on it. OK, so I'll take on the role of beating you to this and I'll try to sneak in a review during the sprint in Davis - maybe even by someone more competent on this than me ;-) I'd only like to better understand your judgment (quote from the PLIP): There are no known risks. There is very little migration needed: two new packages need to be added to the Plone instance and the persistent utility from plone.keyring needs to be instantiated. All existing forms will continue to work. In order to use the newly available protection they can be modified by a single line of TAL in the template and a single line of python in the backend code. by trying it out myself and looking more closely at it before I say more. Refering to your statement: A user interface to manage keyrings as well as a system to automatically rotate keyrings is highly desirable. is of course understandable but I wouldn't even insist on that. There is one question I have already now: Who feels responsible for updating the forms that ship with Plone/AT to make use of this? (or am I missing something?) And don't get me wrong: I have no problem shipping it even without using it right away just to make it readily available. What do others think? Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] review deadline coming up
Andreas Zeidler wrote: [..] answer the second part we first need to distribute those 16 review. however, as i don't think anyone would be too happy to go ahead and do this for you, you should initially each grab at least three of them yourselves: * raphael, you've offered to look at martin's plips — is that still valid? Yes; and I've look somewhat more closely at two already but didn't check in any comments yet I've also spend quite some time on the WebDAV PLIP and that turns out to be non-trivial to test (for me at least) as I never seriously used WebDAV myself (except for demo purposes). Would be great if someone else could give that one a more thorough analysis. Regarding my schedule: as I'm leaving for the States Friday morning I'm hoping to be able to much of the flight time on this as well as Saturday morning (I'm sure the 9 hour time shift will affect my sleeping schedule ;-) On the other hand I also want to prepare a bit for the sprint so we'll see Stay tuned, Raphael i know they're probably a more substantial ones, so i suppose you could leave one or two for someone else * martijn, when will you be able to work on this again? and do you have any preferences about what plips you'd like to review? * tom, i know you were still planning to do the reviews this week, so how much time will you have for this? * danny, could you perhaps go through to see what you think would be okay for you, i.e. not too technical, and grab those? in case there are tickets left unassigned by tomorrow afternoon, say 2pm, i'll try to come up with some suggestions for assigning them, in which case you'll have to take care of finding good reasons to pass those reviews on yourselves... ;) 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/ plone 3.0.5 released! -- http://plone.org/products/plone ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #215: Include new KSS versions
Tom Lazar wrote: just a quick 'heads up' from me that i have no problem with the delay. i'd very much like to see new and improved kss in every new version of plone ;-) I've also no problem with the delay here. cheers, tom p.s. have fun in austria, wish i could be there... Indeed, me too ... Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #215: Include new KSS versions
Wichert Akkerman wrote: Previously Tom Lazar wrote: just a quick 'heads up' from me that i have no problem with the delay. i'd very much like to see new and improved kss in every new version of plone ;-) I sort of agree, but I do want to note that I can not find a reference of PLIP 215 being proposed before. It was submitted by Balazs on December 13 via email to this list (search for new kss version). All team members gave a positive vote as can be seen on http://plone.org/products/plone/roadmap/215 What else are you missing? Raphael As such I would suggest that the framework team only review it after all properly proposed PLIPs have been reviewed and voted upon first and only if there is time remaining to review it properly. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 195 implementation ready for review
Wichert Akkerman wrote: [..] I've implemented this change and updated the review buildout. Wichert. Thanks Wichert! I just added my (final?) comments to the bundle: http://dev.plone.org/plone/browser/review/plip195-dependencies/REVIEW_NOTES.txt Raphael 2008-01-17: === Reviewed the buildout on Linux/Ubuntu-7.10 doing: (i) TTW exploration (ii) running the tests for GS and QI (iii) used the new dependency feature on a set of own products (iv) browsed through the code (changes) of GS and QI No breakage or glitches of any kind noticed. Works as advertized. Code looks clean and solid. Nothing to add from my side. Remarks: (i) I didn't find specific (unit) tests for the new feature (e.g., installing ProductOne results in ProductTwo being installed; BrokenProduct being found as non-installable) Should be trivial to add given what's there already. (maybe I'm blind?) (ii) On merge/release we should probably document the new feature on plone.org, e.g., using a how-to in the docs section and link there from the ChangeLog/HISTORY as well as from the release notes. Overall judgement: +1 ready to be merged (but I wouldn't mind seeing the tests mentioned above) === Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 195 implementation ready for review
Wichert Akkerman wrote: Raphael Ritz wrote: (i) I didn't find specific (unit) tests for the new feature (e.g., installing ProductOne results in ProductTwo being installed; BrokenProduct being found as non-installable) Should be trivial to add given what's there already. (maybe I'm blind?) You are not blind but you need to know where to look. There are tests for the basic dependency handling behaviour in the tests for the setup tool: see the test_runImportStep_dependencies and test_runImportStep_skip_dependencies methods in GenericSetup/tests/test_tool.py Thanks for the pointer. I didn't realize this test now also covers dependencies across products as it originally only covered dependencies within one profile (IIRC). I just updated my notes on the bundle. Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Official submission: PLIP 184, 200, 203 and 204
Wichert Akkerman wrote: Previously Tom Lazar wrote: for the record (as a framework team member) i'd like to support martin on this issue. the formlib wysiwyg support is a *new* feature, and if it happens to *not* work for fckeditor, eventhough wysiwg support used to work for kupu *and* fckeditor prior to formlib, then that's (understandably) unfortunate, but IMHO no show stopper. i appreciate martin's willingness to look into that matter, but by no means would let that influence/diminish my support for plip 200 per se. Let me explain why I don't agree: FCKEditor is reasonably popular and fully supported in Plone 3.0. If it suddenly starts breaking in parts of Plone when people upgrade to 3.1 that is a regression, even if that happens to be due to a new part of the Plone framework. We need to look at this from a users perspective, not from our own. Luckily Raphael already fixed this so the discussion is moot :) While the particular issue is fixed now I don't think this discussion is entirely moot. I agree with Wichert here that we cannot have things breaking simply because people have an add-on installed. In the particular case it was even worse than I first thought because having FCKeditor installed also broke the kupu formlib widget even for people that had kupu selected as personal preference. So I correct my initial classification from boarder line to show stopper. Why am I saying this now that the issue is fixed? Because I want us to be careful when doing code review and remind us that we promised to not break 3rd-party products in this release. (here it was a lack of extensibilty actually) Furthermore, I also agree with Wichert in that we need to look at this from a user's and not a developer's perspective. I don't want to tell my users You know this is a new feature that unfortunately breaks with your current configuration but it wasn't available before anyway What's more: the issue is more central then it might seem at first glance as it is not about WYSIWYG editing a static portlet only but about providing a WYSIWYG widget for *all* formlib based forms which we will see increasingly often in the future. Having such a widget not honoring the current customizability (after all we do offer to select the editor in the personal preferences) would have been a major flaw. Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Organizing the review
Hi team mates, just a quick question regarding how we want to organize the review: While the deadline for submission is only next Saturday (Jan 19) we do already have some PLIP implementations submitted: http://dev.plone.org/plone/browser/review/plip195-dependencies http://dev.plone.org/plone/browser/review/optilude-plipathon-184-200-203-204 http://dev.plone.org/plone/browser/review/optilude-plip202 http://dev.plone.org/plone/browser/review/plip205-portlettypes-multiplemanagers http://dev.plone.org/plone/browser/review/plip207-custom-portlet-managers http://dev.plone.org/plone/browser/review/plip218-addable-portlets-restrictions-and-changes and some where I'm not exactly sure but where I think it makes sense to start looking at more closely: http://dev.plone.org/plone/browser/review/dreamcatcher-plip187 http://dev.plone.org/plone/browser/review/plip208-localroles http://dev.plone.org/plone/browser/review/plip217-workflow Now in the interest of time I think it makes perfect sense to start seriously looking at those submitted already. Ideally, everyone from the team should look at everything but often this simply doesn't work out so we might want to make sure we spit the work such that all PLIPs get consideration from at least two or three team members. Questions or issues arising should of course be brought to the attention of the entire team, e.g., by posting them here. I offer to first look more closely at Wichert's GS dependency handling as well as Martin's stuff. I might also be able to comment on Sidnei's WebDAV work (though I can't test on Windows; Linux and Mac only here). What do others think? Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Organizing the review
Wichert Akkerman wrote: Raphael Ritz wrote: Ideally, everyone from the team should look at everything but often this simply doesn't work out so we might want to make sure we spit the work such that all PLIPs get consideration from at least two or three team members. Questions or issues arising should of course be brought to the attention of the entire team, e.g., by posting them here. I think it make sense to look a bit at the roles of people in the framework team. Specifically I would like Danny to look at all user interface aspects of all PLIPs. That is his area of expertise and why we asked him to be part of the framework team. Sure enough but I take the liberty to comment on the UI if I see a need for this and Danny is of course free to comment on the code if he wants to but obviously you have a point here. Guess I only want to avoid that we develop an attitude: Oh, yeah, the UI that's Danny's business so I don't need to care ... (exchange 'UI' and 'Danny' with whatever you want to consider as well). Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Official submission: PLIP 184, 200, 203 and 204
Martin Aspeli wrote:
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
Hi Martin,
just playing with this I noticed the following:
If I install FCKeditor, select this as my personal
preference (under WYSIWYG editor) and then try
to create or edit a static portlet I get the attached
traceback.
I know it's borderline and I don't know how popular
FCKeditor is but so far it's been OK to offer and use
them both on a site.
Just so people know.
Raphael
-
Time 2008/01/15 16:35:03.707 GMT+1
User Name (User Id) admin (admin)
Request URL
http://localhost:8080/martin/++contextportlets++plone.leftcolumn/Assignment/edit
Exception Type KeyError
Exception Value 'editor'
Traceback (innermost last):
Module ZPublisher.Publish, line 119, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 42, in call_object
Module plone.app.portlets.browser.formhelper, line 124, in __call__
Module zope.formlib.form, line 770, in __call__
Module zope.formlib.form, line 764, in render
Module plone.app.form._named, line 26, in __call__
Module Shared.DC.Scripts.Bindings, line 313, in __call__
Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
Module Products.PageTemplates.PageTemplateFile, line 129, in _exec
Module Products.PageTemplates.PageTemplate, line 89, in pt_render
Module zope.pagetemplate.pagetemplate, line 117, in pt_render
Module zope.tal.talinterpreter, line 271, in __call__
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 891, in do_useMacro
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 536, in do_optTag_tal
Module zope.tal.talinterpreter, line 521, in do_optTag
Module zope.tal.talinterpreter, line 516, in no_tag
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 957, in do_defineSlot
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 536, in do_optTag_tal
Module zope.tal.talinterpreter, line 521, in do_optTag
Module zope.tal.talinterpreter, line 516, in no_tag
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 861, in do_defineMacro
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 957, in do_defineSlot
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 536, in do_optTag_tal
Module zope.tal.talinterpreter, line 521, in do_optTag
Module zope.tal.talinterpreter, line 516, in no_tag
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 534, in do_optTag_tal
Module zope.tal.talinterpreter, line 516, in no_tag
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 949, in do_defineSlot
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 891, in do_useMacro
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 861, in do_defineMacro
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 957, in do_defineSlot
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 536, in do_optTag_tal
Module zope.tal.talinterpreter, line 525, in do_optTag
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 824, in do_loop_tal
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 536, in do_optTag_tal
Module zope.tal.talinterpreter, line 521, in do_optTag
Module zope.tal.talinterpreter, line 516, in no_tag
Module zope.tal.talinterpreter, line 346, in interpret
Module zope.tal.talinterpreter, line 745, in do_insertStructure_tal
Module Products.PageTemplates.Expressions, line 221, in evaluateStructure
Module zope.tales.tales, line 696, in evaluate
- URL: index
- Line 104, Column 10
- Expression: PathExpr standard:'widget'
- Names:
{'container': Assignment at /martin//,
'context': Assignment at /martin//,
'default': object object at 0xb7d6f528,
'here': Assignment at /martin//,
'loop': {'widget': Products.PageTemplates.Expressions.PathIterator object
at 0xd4aa5cc},
'nothing': None,
'options': {'args': ()},
'repeat': Products.PageTemplates.Expressions.SafeMapping object at
0xd27d48c,
'request': HTTPRequest,
URL=http://localhost:8080/martin/++contextportlets++plone.leftcolumn/Assignment/edit,
'root': Application at ,
'template': ImplicitAcquirerWrapper object at 0xd27d22c,
'traverse_subpath': [],
'user': PropertiedUser 'admin',
'view': Products.Five.metaclass.EditForm
Re: [Framework-Team] Re: Official submission: PLIP 184, 200, 203 and 204
Martin Aspeli wrote: [..] I agree, but this may just as well be a bug in FCKeditor. Since that's not part of Plone core, it's a bit hard to account for it (we can't test every third party product). That said, we do want this release to be nice on third party products, so we should fix it. Fixing it is likely to be easy, Indeed. I just checked in a fix at http://dev.plone.org/plone/changeset/18957 Please double check anyone. Raphael ___ 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!
Ricardo Newbery wrote: Thanks again Sidnei, [note to framework list: let me know if I should take this discussion off list] No problem with me. You might want to consider cross-posting or moving to plone-devel depending on the audience you want to reach. Just my 2 cents, Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Official submission: PLIP 184, 200, 203 and 204
Martin Aspeli wrote: [..] Cheers, and merry Christmas :) Thanks for all your contributions and Merry Christmas, Raphael Martin [1] http://dev.plone.org/plone/browser/review/optilude-plipathon-184-200-203-204/REVIEW-NOTES.txt ___ 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] Re: voting process
Andreas Zeidler wrote: On Dec 20, 2007, at 9:04 AM, Raphael Ritz wrote: [..] 1. Do we give our votes here via the list or on the website as comment or both? i'd prefer them to be on the plip pages themselves. that'll make counting and accepting plips much easier. OK, then we need to face plone.org's current slowness but I agree ... BTW: I started to add some comments in my voting comments ;-) but I don't like that pattern as it introduces a second channel for discussion. Any chance we can have the comments added to plips be forwarded to this list? 2. What PLIPs are to be considered? Currently I assume we have to deal with all PLIPs listed at http://plone.org/products/plone/releases/3.1 i've updated that list a couple of days ago, and i think wichert added #220. but it seems there are still a couple of others missing, #187 and others = #218. i won't have time to update that list and do more reviews until late tonight or tomorrow, and i'd also appreciate it if somebody else could double check the submitted plips from the list. I would very much preer to have this list updated as soon as possible as we might waste a lot of time and create a lot of confusion if we need to figure out which of all the plips around is meant to be submitted for 3.1 3. How many votes do we consider necessary for acceptance or rejection? Ideally, all members should vote on all PLIPs but what if not? What if people disagree? all members should vote on all plips. if not, i'll be responsible to _remind_ them, i suppose... :) and in case we don't agree i think we should discuss matters before possibly resolving into a majority vote. that's just my opinion, though — other thoughts are welcome! Fine with me [..] ps: i'll volunteer to do the counting once all votes have been casted. Thanks Andi, Raphael -- 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP 197 - FeedParseer
Hi, don't know whether this is even submitted for 3.1 http://plone.org/products/plone/roadmap/197 but I agree with Christian that we should not include a third-party library literally in the Plone core source distribution. +1 on this PLIP from me anyways. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Vice - RSS link
Raphael Ritz wrote: Hello again, while PLIP 192 (Vice Outbound Syndication) http://plone.org/products/plone/roadmap/192 isn't even submitted to 3.1 (AFAICT) it contains a point that's worth noting and that might go into 3.1 IMHO. It's about changing the way the RSS link is handled. Making that viewlet-based is definitively an enhancement. So if Derek or Florian or others want to do this I would support it. Raphael Ups, I didn't mean to imply I'm pushing something that's not even submitted for 3.1 in a way changing the process we agreed upon initially. Please ignore the post and sorry for the noise, Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #213: Prepare for better Syndication
Florian Schulze wrote: Hi! I propose the following PLIP: http://plone.org/products/plone/roadmap/213 It's a very small one, but with a small risk, so I think this should go the proper PLIP way. The implementation just needs to be backported, which means removing a few lines and using the newer version of plone.app.layout from trunk. +1 but I agree with Andi on the need to document this properly. Raphael Regards, Florian Schulze ps: I started a draft for another, bigger one, which will probably be expanded by MJ tomorrow, but I provide the link for anyone interested: http://plone.org/products/plone/roadmap/212 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: My PLIPs for 3.1
Alec Mitchell wrote: [..] I will be writing a PLIP shortly which will hopefully make any merging of CMFPlacefulWorkflow into the workflow tool unnecessary. The idea is adapter based workflow assignment. By default all IDynamicType objects would be assigned a workflow chain using an adapter that does the normal lookup in portal_workflow, but alternate means could be provided with simple adapters. CMFPlacefulWorkflow/CMFPlone would probably just override the default adapter with one that relies on acquisition, but there may be an even more elegant way. Sneaking in here because of the phrasing ...Plone would just override ... In terms of ZCML overrides I think we shouldn't do that as there can always only be one override for a specific component at most (please correct me if I'm wrong). I thought the way to be more specific if needed is e.g., by adding qualifiers or introducing more specific interfaces. But I'm confident Alec will get it right ;-) Raphael Alec ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
Wichert Akkerman wrote: [..] If you draw this up you basically get a matrix of views with a content-type axis and a tile-type axes. Something like: | main content | portlet | search result | folderlisting ---+---+---+-+ Topic | topic_view.pt | topic_portlet.pt | topic_list.pt | topic_list.pt Page | page_view.pt | page_portlet.pt | page_summary.pt | page_list.pt Link | redirect.pt | link_portlet.pt | link_list.pt| link_list.pt you could register them like this: plone:tile template=page_view.pt for=.interfaces.IDocument name=portlet / and you could use them like this: tal:tile replace=python:tile(obj, style='list') .. /tal:tile is that something along the lines you had in mind? are you planning on turning that into a plip? 3.1 material? certainly, the Zope CA seems to lend itself for expressing such scenarios (i.e. adapting a content object to a certain teaser type/ teaser interface, which then gets picked up by certain viewlet/portlet managers etc.) I think this is too much of a change for 3.x. However it is a direction that I think is worth investigating for 4.0. I'm not sure if I will have time to work on it though. I'm very much in favor of this approach but I agree that this is not for the Plone 3 series. Furthermore, I'm not sure that the underlying infrastructure should be dealt with in Plone. There could be interest to support this at the CMF level even (by enhancing the types tool maybe? providing a registry for tile types? just thinking out loud ...) Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIPs for 3.1
Martin Aspeli wrote: [..] In the spirit of thinking aloud, I think even that is not general enough. I think the easiest approach will be to use pure Zope 3 and register these as different views providing different marker interfaces or something like that. That way, you can tile something that doesn't have an FTI, or use different tiles for different variations (think subtyping). Agreed (/me makes mental note to stop thinking in the old categories ...) Anyway, let's take this to the plone-dev list and talk to Malthe, who I believe has got code for some of this. +1 Raphael Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] review bundle for PLIP 195 ready
Tom Lazar wrote: [..] i've installed the buildout and done some TTW testing in the ZMI and in the plone control panel: everything worked as expected. in fact, the only difference in behaviour was that installing ProductOne did indeed also install ProductTwo, there were none of the previously reported effects observable such as locked/un-uninstallable products etc. ... because Wichert changed it more or less right after I had brought this up ... there is, however, one issue i'd like to bring up, namely if it would be a desirable behaviour, if uninstalling ProductOne would also uninstall ProductTwo. since there is a current trend of 'exploding' products into smaller, re-usable components i could imagine that quite a few users might get frustrated when they install a product 'just to check it out' and that then populates the list of installed products with several dependencies which they then need to de-install manually. two weeks later nobody will remember what ProductTwo does or how it got installed. any ideas on this? while I think I see your point I would be against making that the default because it could easily break in situations where you have multiple cross dependencies. Like product A depends on B but product C also depends on B. Then uninstalling A will break C (you can take that further if you like). Keeping track of those kinds of dependencies to do the right thing on uninstall might be tricky. Or to give another example: Just imagine you have installed quills ;-) indirectly via quills.remoteblogging. Now you realize you don't don't want or need the remote blogging part but you do want to use the core blogging features. How would you go about uninstalling remote blogging without uninstalling quills? On the other hand it could be convenient to offer it as an option in the UI to list the dependencies on uninstall and to ask whether they should be removed (or which ones). But for this to be helpful the quickinstaller would still need to maintain a dependency matrix for the above mentioned reason. also, there's this paragraph in the plip that i don't understand: --snip-- One possible problem is that GenericSetup will only warn if a dependency is missing. This means that if a required product has not downloaded and installed in the instance by the user he will not get a proper error message. What's not clear? A warning isn't an error meaning GS will happily install a product even though a dependency might be missing. It will issue a warning (in the event log) but who cares about warnings ;-) Obviously the product will be broken in such a situation therefore it would be better for GS to fail and raise an error instead. But this is GS territory where we are more on the user side. So maybe we should bring this up on zope-cmf? I assume Tres or Yuppie might have an opinion here as well. This problem does not exist for products shipped as eggs: eggs allow the developer to specify dependencies which will be enforced by tools such as buildout and setuptools/easy_install. --snap-- other than that +1 from me, definitly! +1 from me as well. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs for 3.1
Andreas Zeidler wrote: On Dec 4, 2007, at 12:35 PM, Tom Lazar wrote: i'll take a look at the plips and check out their bundles (including wiggy's #195) during the weekend and will report by sunday evenening. fair enough, but let's make deciding on the acceptance of PLIPs a higher priority for the time being, shall we? i mean, reading and thinking about them a bit should take as long as doing a review or even playing with a bundle, and imho people want to know asap if their PLIPs have a chance of making in into 3.1. I hope I can set aside some time tomorrow. After all, Martin submitted not just one thing but a whole list ;-) Raphael 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/ plone 3.0.3 released! -- http://plone.org/products/plone ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] review bundle for PLIP 195 ready
Wichert Akkerman wrote: I have prepared a review bundle for PLIP 195: https://svn.plone.org/svn/plone/review/plip195-dependencies this is a standard buildout, so you can get everything up and running using the standard mantra: svn co https://svn.plone.org/svn/plone/review/plip195-dependencies cd plip195-dependencies python2.4 bootstrap.py bin/buildout bin/instance fg aside from the updated GenericSetup and CMFQuickInstallerTool I added two very trivial products that demonstrate the dependency support. If you install ProductOne you should see ProductTwo appear automatically. Maybe there's something wrong on my side but when calling buildout I just got: [EMAIL PROTECTED]:~/buildouts/reviewing/plip195-dependencies$ bin/buildout Getting distribution for 'plone.recipe.plone'. Got plone.recipe.plone 3.0.3. Getting distribution for 'zc.recipe.egg'. Got zc.recipe.egg 1.0.0. Installing plone. While: Installing plone. An internal error occured due to a bug in either zc.buildout or in a recipe being used: ValueError: too many values to unpack :-( Raphael While testing this I ran into a problem we currently see with portal_setup: the setup tool is currently registered as a utility. This means that it you access it through getToolByName and import a profile none of the import steps will be able to use self.REQUEST. I added a work-around for that (see the XXX comment) in this review bundle, but we need to fix that in Plone 3.0 as well. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: proposed plone 3.1 timeframe
Alexander Limi wrote: On Thu, 22 Nov 2007 01:59:23 -0800, Martijn Pieters [EMAIL PROTECTED] wrote: I see both sides of the coin here, Wichert is correct in insisting on shorter release cycles, Martin is correct that December is not the month to do this. I won't have much time to review bundles over New Year for example, not with a move coming up at the end of January as well. Can we add just 2 weeks or so to Wichert's schedule? +1 for adding a couple of weeks since Christmas throws things off by that much. I agree with the other sentiments here that it's not about the time since 3.0, it's about the time from announcement of the deadlines until the actual deadline. 1.5 months is way too short, particularly with Christmas in there. I agree with Wichert's goals, but I still think there should be some more wiggle room the first time around. :) [1.5 days off-line and a lot to catch up with ;-) ] FWIW: while I agree with Wichert in principle I also do think his proposed schedule is somewhat tight given Christmas. So I would be fine with adding 1 or even 2 weeks to his proposed schedule (not more!) but I could also live with his original proposal. Though I agree with Martin that we might loose those contributions that get only serious consideration once a deadline is in sight but OTOH I consider that a non-issue if we aim for shorter release cycles in general. Maybe we could even indicate an explicit time line for 3.2 right away as well? Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Terminology change: migration - upgrade
Alexander Limi wrote: [..] Any objections? no, not from me - as long as you don't break any code ;-) Raphael PS: didn't we have that discussion month ago already? --Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Remove community_workflow?
Martin Aspeli schrieb: Hi guys, In reference to https://dev.plone.org/plone/ticket/6501, I *think* it would be safe and sensible to remove community_workflow and community_folder_workflow from the standard Plone 3 install, and re-title the plone_workflow and plone_default_workflow to be called Community site workflow and Community site folder workflow or some such. That is, the new community_workflow's are more or less identical to the old (but updated/sanitised) plone_workflow's. We can't remove the plone_* ones since too many things depend on them, but that's just a matter of the id anyway. Objections? No, not from me. Should be fine as far as I can see. Raphael Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: plone.theme - one more package for Plone 3?
Tom Lazar schrieb: [..] FWIW: i like this feature a lot and would be very pleased with its inclusion in 3.0 final. judging from my own frustration that i've had so far with five based views 'messing up' skin layers they were not intended for i think any possible integration issues will well be paid for by the amount of frustration we will spare plone integrators (and the number of requests for help on plone-users!) I'm with Tom here but also with Whit meaning it's wiggy who should have the last say. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Community workflow and plone workflow
Martin Aspeli schrieb: Hi guys, Hi Martin, We've determined that removing plone_workflow won't work - it breaks too many tests, which make silly, implicit assumptions about the default workflow. which is bad testing style then but anyway ... :-( However, we don't want this to be the default on freshly created Plone sites, because it is not appropriate for most sites - particularly now that we turned of member folder creation by default. Alex just found a number of security/access control related bugs which make the OOTB user experience a bit painful (basically, only admins can add content on a freshly created site at the moment, which is silly). But not too surprizing as the memberareas used to be the only places where regular members could do that up to now. Therefore, I've switched the default, but invoked a hidden 'testfixture' extension profile in Products.CMFPlone.tests.PloneTestCase. Do I understand correctly that testes now run with different security settings compared to a TTW created Plone site? Do we really want that? Note that other packages which make workflow assumptions can get this by passing extension_profiles=['Products.CMFPlone:testfixture'] to setupPloneSite(). I expect we may find a few more of these assumptions. I'd rather they were fixed, but for now we have a workaround. I've run $ zopectl test -s plone as well as the CMFPlone and ATContentTypes tests and fixed what I found. There are some failures around, but most of them have been there for a while and hopefully the relevant people know. Anyway, Alex also made the point that plone_workflow and community_workflow are virtually identical. IIRC they are. In essance, it's just a renaming (plus the addition of the reader and editor role) It's pretty much impossible to remove plone_workflow at this stage, but we *can* change its title to be Community workflow. As long as we are only concerned about a more meaningful UI that should be fine. Is there a reason to keep both around, or can we just merge the two? Not having looked more closely at this recently (sorry, I've been out of the loop for a while) I would assume they could just be merged. Raphael Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: The big 3.0 ;)
Martin Aspeli schrieb: [..] There is a general developer mis-conception that Plone's not *too bad at* but sometimes we all do it: More options == better. Could we maybe return to the issue that triggered this discussion, namely whether or not to bann the smart folder settings from the Plone control panel. In my view we should not do this because: 1. removing something that's been around for a while now just confuses people. 2. In the long run (aka when at some point moving to Zope 3 entirely) there will be no ZMI anymore as we know it today. 3. Smart folders (aka Topics) are special in various ways and admittedly they are way more complex than the other regular content types. Simply saying that many people don't need their UI-configuration options may fall short here because I assume many sites don't make much use of topics (if at all). On those sites where they are used heavily I claim these options are desperatly needed. On a related note: let's not forget that one of the strong points of Zope/Plone has always been the possibility to do many things TTW from a browser. In many real life situations, site admins don't have file system access to the server deploying their site which defeats in my view the current tendency to simply move everything to the file system and then saying: Oh, well, just provide your own view class/whatever and override the default in your config.zcml. For those site admins this is simply not an option. (And note that I am not talking about TTW *development*, I'm talking about *site configuration*.) Just my 2 cents. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
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
[Framework-Team] Re: new workflows
Hanno Schlichting schrieb: [..] Do we really want to update existing sites? They already have their customized workflows and I don't quite see why we should pollute their workflow tools with any new ones. IIRC we discussed this at the Archipelago sprint and at least at that time there was agreement that we do *not* migrate existing sites. Having some fool-proof docs on how to enable them nevertheless wouldn't hurt of course. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: new workflows
Martin Aspeli schrieb: I general I agree; it's mostly a practical issue here because the old API for adding workflows to the tool is gone and I simply don't know whether/how GS supports doing only parts of an import step (import wf x and y but leave z alone; don't touch the chains ...) but maybe it's just me and all this turns out to be a non-issue. I don't think it's that hard, and I will give it a shot. The strategy would be to run just the import handler that updates the workflow object, not the whole workflows.xml one. I'd have to look at it a bit more carefully, though. We need to be careful here indeed. To the extend that I've understood how GS works this isn't exactly straight-forward. CMFCore.exportimport.workflow._importNode calls self._initProperties(node) self._initObjects(node) self._initBBBObjects(node) self._initChains(n which - in a custom import handler - can be easily restricted to just call self._initObjects(node) which comes from GenericSetup.utils.ObjectManagerHelpers. This iterates over all 'object' children in the node, creates them only if they are not yet there (which is exactly what we want) but then also invokes the import handlers for **all** 'object' children (not really sure on this one, though - if this could somehow be restricted to objects newly created we would be done). At least calling it on all childern (here workflow instances) is not what we want here, because DCWorkflow.exportimport.DCWorkflowDefinitionBodyAdapter._importBody calls _initDCWorkflow unconditionally on all workflow instances enforcing the settings found in the XML files irrespective of any previous settings. This is where it becomes dangerous and this is why I think we cannot (easily) rely on GS here. Please prove me wrong! And just to clarify: what I know fore sure is that when you import a wf via an extension profile, do some customizations TTW (e.g., change permission settings for a state) and then reapply that same extension profile your TTW customizations are gone. This is why we have this discussion. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: new workflows
Martin Aspeli schrieb:
[..]
I need to look at this in more detail, but we'd need to find a way of
doing it at a lower level. Hell, I'd copy the XML-parsing code and
make it more defensive if necessary. :)
My hope (without looking at the code in detail) was that the logic
that parses the Definition.xml file and creates states, transitions
and so on is in a separate function to the logic that parses the main
workflows.xml file (which points to workflows to install, but also
does type mapping and what not). If we could invoke this logic
separately, we could make sure it was only ever called on XML files
corresponding to non-existant workflows.
I just looked into this a bit more and indeed it isn't that hard ;-)
The following at least works for me as a script to be run via
zopectl run scriptname
on a Zope instance with a Plone site called 'plone'
---code starts -
from Products.DCWorkflow.DCWorkflow import DCWorkflowDefinition
from Products.DCWorkflow.exportimport import \
WorkflowDefinitionConfigurator, _initDCWorkflow
new_workflow_ids = ('wf1','wf2')
site = app.plone
wft = site.portal_workflow
for wf_id in new_workflow_ids:
if wf_id in wft.objectIds():
print %s already there; doing nothing % wf_id
continue
body =
open('/extra2/sites/bccnappdev/Products/BCCNApplications/profiles/default/workflows/reviewer_comments/definition.xml','r').read()
# this needs to point to the right definition file(s) of course
encoding = 'utf-8'
wft._setObject(wf_id, DCWorkflowDefinition(wf_id))
wf = wft[wf_id]
wfdc = WorkflowDefinitionConfigurator(wf)
( workflow_id
, title
, state_variable
, initial_state
, states
, transitions
, variables
, worklists
, permissions
, scripts
) = wfdc.parseWorkflowXML(body, encoding)
_initDCWorkflow( wf
, title
, state_variable
, initial_state
, states
, transitions
, variables
, worklists
, permissions
, scripts
, site # not sure what to pass here
# the site or the wft?
# (does it matter at all?)
)
print Added %s % wf_id
import transaction
transaction.commit()
-- code ends ---
From here it shouldn't be hard to turn this into a migration step
in case we want one.
Raphael
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: branching moment
Hanno Schlichting schrieb: [..] Selecting a new team is indeed our last responsibility (besides thinking about ways to improve the process). We can start doing that now or in a few weeks. I don't have a strong opinion about this topic. I agree with Hanno here on all accounts. Other than that, I'm +1 for staying on trunk at least until we enter RC phase but I'd prefer even until we get the first release out. Raphael Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] plip 101 - batch and sort
Hi guys, this is just to let you know that student of mine, Florian Kamm, is implementing a solution for PLIP 101 http://plone.org/products/plone/roadmap/101 Sortable tables need to be improved, the javascript needs to be cleaned up and if the table is part of a batch it should handle the whole batch, not only the visible part. You can get the current code from http://plone.org/products/batchit I know that this Plip isn't on our current agenda but still I thought I just let you know. As it's AJAX-based it might make for another nice use case in that context. Florian and I are willing to donate the code to the foundation and to do the integration work should the team decide to go for it. Let me know what you all think. Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] AJAX decision must be made THIS WEEK
Martin Aspeli schrieb: Hi guys, Hi Martin, so without any further arguments/discussions/justifications/emotions/... I'm +1 on including AZAX/KSS - which implies -1 on Bling (sorry Ben) Raphael We've meandered, wondered, hued and hawwwed for long enough. Jon co need to know what the Ajax story will look like by (as in *before*) October 15th, when Plone Conference timetable is to be finalised and programmes printed. I'm also sick of waiting. I want to put this to a vote right now. Please give your +1's and -1's. Given the nature of this, I'm inclined to let non-voting developers voice a +1 or -1 *provided* they mark their answer clearly as being from a non-voting member, to avoid anyone mis-counting. I would like to tally up the votes Friday and make an edict, unless anyone has strong objections. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
