Re: [Framework-Team] Re: Plone 4 dependencies
On 01.06.2009, at 21:42, Hanno Schlichting wrote: I think we can move all the admin-UI stuff like preference screens, folder_copy, object_rename and author pages and the like from CMFPlone to browser views in Plone 4, as these tend not to be customized that often. +1 also, those views contain more functionality than the ones mentioned below and thus the benefit of migrating those rather sooner than later is a lot bigger. IMHO those changes are definitely plone 4 material. cheers, tom I wouldn't want to see document_view, folder_listing and the more commonly customized templates to be changed in Plone 4, though. Changing these will break lots of customizations out there and I only want to do that once we have figured out the complete story for TTW editing and new-style default theming. As long as we have Archetypes and any AT-based add-on, we won't be able to ditch portal_skins anyways. It's whole widget machinery and base_* are too tightly based on nested skin layers and lots of magic. 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] Re: Plone 2009: Going from here
On 13.05.2009, at 01:23, Steve McMahon wrote: By my reading, here is the list of those willing to participate in a Plone 4 framework team: Raphael R. Ross P. Matthew W. David G. Calvin H.P. Alec M. Erik R, Laurence R. [...] If you'd like your name added, or removed, please put in a message soon. i think, i just disqualified myself by not having read the framework list for over two weeks now :( sadly, that is a pretty accurate indicator of my current resources for unpaid, non-family related commitment in general, so i'm afraid i'll have to pass. tom ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.5
for the record, i think this is a great idea. this will also take some weight off of the 4release, since some of its low-risk components will have had some real-world usage by then. also, it should make migrations from 3.x to 4.x easier, i could imagine. i'm also more than fine with eric as 3.5 release manager. thanks for volunteering, eric! just my €0.02, tom On 05.05.2009, at 13:44, 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. In order to frame the scope of such a release I made a listing of some of the potential features for such a release at http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The list is both non-exclusive and non-binding in the recommendations. The envisioned timeline for a Plone 3.5 release would be to aim for a final release either by the time of the conference or by the end of this year, giving us six months or a bit more for it. By aiming for an after-summer beta deadline we will have a chance of leveraging some Google Summer of Code contributions for such a release. When it comes to the official personal involved in such a new major release, I'd like to suggest a slight deviation on our process. As many to all of the features changes in question for the 3.5 release have so far been in the scope of the 4.0 release, I'd suggest to appoint the entire 4.0 framework team to be the official team for 3.5 as well. This forces them to get involved with the process in a more defined and clear way now. On the side of the release manager, Wichert has signaled that his workload as a freelancer will not allow him to take over the shepherding of a new major release. We do however have with Eric Steele of PSU fame a well-known interested candidate for the position. This is only a proposal that needs community feedback and encouragement at this point to make it into an official roadmap. The next steps are to have an open discussion about this for the next one to two weeks. If it meets general favor, we will appoint the new/old framework team and let them recommend a release manager to the Foundation board for official nomination. Cheers, 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] Working out-of-the-box WebDAV (PLIP 187) in Plone 3.4 or later
On 08.04.2009, at 11:02, Graham Perrin wrote: A question for FWT: * instinctively, where/when on Plone roadmap do you envisage PLIP 187? given that 3.3 is in rc state, 3.4 will be the earliest possible release. it would be great, if this work would be picked up and completed. i'm looking forward to reviewing it anytime :) cheers, tom ___ 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)
On 07.03.2009, at 14:38, Andreas Zeidler wrote: On Jan 18, 2009, at 1:44 AM, Ricardo Alves wrote: - Change the view name to ics_view, which is the same name used for a single event. I find the current name (calendar.ics) a bit confusing, because I would expect it to be the downloaded file's name, but that will be [CONTEXT_ID].ics. i've decided to go ahead and indeed change the name (to @@ics_view) before the first release of plone containing this feature. i think you're right that it's better to be consistent (and less confusing as well). thanks for pointing this out. for the record: +1 from me and thank you, too to ricardo for noticing this; good catch! tom 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #234 Review Revisions
On 12.02.2009, at 13:19, Andreas Zeidler wrote: On Feb 12, 2009, at 1:05 PM, Andreas Zeidler wrote: [...] i did notice that test (which is why i added almost in almost none of the changes are actually tested ;)), but found that one was far from enough. anyway, tom will make sure there are enough now... ;) that said i couldn't resist to quickly check the branches for newly added commits... afaics the only tests you actually added are the ones for the calendar portlet[*], though. imho, this is not enough. i think _all_ places affected by the changes in the PLIP need to be tested for correct behaviour for the case when the site root is _not_ the navigation root. of course the other case, i.e. having the nav-root _at_ the site root like it is the default in plone, is already well-tested and not the scope of this PLIP anyway. but i don't think many people have actually used this feature before (as it was partly broken), so we really need more thorough tests for this variant (separate nav-root) now that it has become feasible... I have reviewed the changes in the documentation and in the three affected packages since december and have conducted another local TTW test. The test showed that the application of INavigationRoot worked as advertised. While I personally still feel that the switch of the root in the navigation tree once you reach a new root is kind of 'creepy' I realize that a) this is intended and b) that in actual deployment the sub-roots are usually served under different domains from the front end webserver, so the effect won't be observable to users. While I agree (with andi), that in a perfect world, this PLIP would come with more tests, I also agree (with calvin, optilude etc.) that this PLIP is by nature more a bug fix than a new feature. I don't think we can reasonably expect that all fixes to Plone must come with 100% test coverage, or else they will not be accepted. Seeing that most changes are actually in template markup and not so much in code and given the test of the base portlet and that no existing tests break I vote +1 on this. Can I guarantee that it absolutely won't break anything? No. Am I convinced that Plone is better with this PLIP than without it? Yes :-) cheers, andi [*] http://dev.plone.org/plone/changeset/24893 -- 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #234 Review Revisions
thanks, calvin! i'll take a look at it ASAP, which probably will mean saturday, though... also thanks for the changeset url, that kind of stuff is really helpful for reviewers (*hint* *hint* to other list members ;-) cheers, tom On 10.02.2009, at 06:55, Calvin Hendryx-Parker wrote: Hi Team, I just committed my revisions based on the initial review of PLIP 234. I also have included some more docs about the PLIP here: http://dev.plone.org/plone/browser/review/plip234-inavigationroot-fixes/PLIP_234_README.txt I believe I have addressed all of the concerns brought up by the reviewers. There is a summary of these changes in the PLIP_234_README.txt file. I added tests for some new changes to the calendar tool and found that I had already written tests for the viewlet code changes that didn't get considered in your diffs, but those tests still pass. Those tests are found here: http://dev.plone.org/plone/changeset/23315 Please let me know if you have any questions at all. Cheers, Calvin -- S i x F e e t U p , I n c . http://www.sixfeetup.com Phone: +1 (317) 861-5948 x602 cal...@sixfeetup.com ANNOUNCING the first Plone Immersive Training Experience | Sept. 10-11-12, 2009 http://www.sixfeetup.com/immerse ___ 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 #234 Review Revisions
absolutely fine by me. it would be great, though, if you could deliver the final version before wednesday, then i could review it on the last day of the berlinale-sprint here, after that i will be really busy with catching up on stuff. cheers, tom On 08.02.2009, at 07:24, Calvin Hendryx-Parker wrote: Hi All, I have addressed most of the issues in the review of my PLIP, but I have a couple more tests in addition to the ones I have added that I'd like to include before the final review is made. I'd very much appreciate it if I could have another day to include these so I can be sure that my PLIP will be included with Plone 3.3. Thanks, Calvin -- S i x F e e t U p , I n c . http://www.sixfeetup.com Phone: +1 (317) 861-5948 x602 cal...@sixfeetup.com ANNOUNCING the first Plone Immersive Training Experience | Sept. 10-11-12, 2009 http://www.sixfeetup.com/immerse ___ 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: Final review report
thanks steve, for the summary report! there's only one thing i'd like to point out (or rather make explicit), namely, that: On 04.02.2009, at 17:48, Steve McMahon wrote: [...] PLIP #234: Standardizing our use of INavigationRoot Review Complete: -2 does not mean, that it is flat out rejected. both reviewers (i.e. andi and myself) have stated, that the current deficits are fixable within the second review phase. AFAIK calvin has already started to work on it, based on our reviews. like i said, i just wanted to state that more clearly to prevent any confusion, cheers, tom ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 243 review buildout available
i have updated my review after the recent changes: --snip-- Second review after fixes (2009-02-02) -- After fixes by Wichert and Danny the picture looks much prettier :-) * All but two tests passed. One is explicitely related to another ticket and irrelevant to this PLIP. * The other simply failed due to the changes made by this PLIP, so I took the liberty of `fixing it on the spothttps://dev.plone.org/plone/changeset/24828`_ * Manual tests worked fine without anything unexpected. * I do think the icons look too different from the rest of Plone's default look but that's just my personal taste, no showstopper. conclusion (updated) After the recent changes I am now +1 on merging. --snap-- On 01.02.2009, at 13:33, Danny Bloemendaal wrote: I added my review notes: PLIP 243 framework UI review by Danny Bloemendaal (ender_), 2009-02-01 == I reviewed this bundle and it all looks very familiair to me (ok, the markup and ideas where taken from our plone intranet) ;-). Anyway it all looks good and works as expected (the bugs mentioned below seem to be fixed). I added some css and icons to make it look good (imho). One remark: I'd like to see a time stamp as well in the revision dropdowns when viewing diffs. There can me more than one revision during the day and then the time information helps. Conclusion -- +1 to integrate. On 18 jan 2009, at 00:50, Wichert Akkerman wrote: For reference here are the implementation notes. They are also present in the README.txt in the buildout itself. Implementation notes This buildout contains the base implementation for PLIP 243: replace the standard workflow history viewlet with a content history viewlet. This buildout contains two changes: - plone.app.layout has a new content history viewlet. This viewlet shows both versioning and workflow changes, and provides direct options to show the differences between versions, review an older version or revert to an older version. - a new history view was added which provides a much simpler way to show the differences between different revisions. Needed documentation changes User manuals should be updated to show the content viewlet and describe the actions it exposes. Outstanding issues -- - the html_diff code difference view can trigger a UnicodeDecodeError, so I disabled it for now. For some unknown reason this only happens in the history browser view. The exact same diff works fine when shown via the version_diff CMF page template. - the CSS and icons needed for the content history viewlet are still missing. My CSS skills are too limited and my graphics skills non-existant, so someone else will need to tackle this. I can show screenshots of the viewlet as it is running on a customer site if desirable. - it might be desirable to add a migration step to Plone to remove the old history action. - the permission used for the @@history form may need to be verified -- Wichert Akkerman wich...@wiggy.netIt 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
On 30.01.2009, at 21:56, Wichert Akkerman wrote: Previously Tom Lazar wrote: FYI i have completed my two remaining reviews and have additionally reviewed #243 which was without a review. I've fixed the problems you saw with #243. i've updated my local buildout and the the site works fine now, i do get some 404 for the images in the timeline (http://localhost:8080/newsite/history_compare_with_current.png ) etc, no showstopper, obviously, but if you can fix that still today i can give your review an unconditional +1 Might I request that review comments are emailed to the PLIP author? meanwhile i've spoken to each on irc, next time i'll send mails. cheers, tom Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP Tallies
FYI i have completed my two remaining reviews and have additionally reviewed #243 which was without a review. there are still outstanding reviews from raphael, witsch and mj (or have they perhaps not updated the pliptallies page[1]?) and IMO #243 would also warrant a UI review! i have included all reviews inside the bundle with a REVIEW-NOTES.txt as per convention and have additionally posted my review as a comment at the plip page. i have not mailed the authors or this list with each individual review. that's all for now, gotta run! cheers, tom [1] https://dev.plone.org/plone/wiki/PLIPTallies33 On 29.01.2009, at 10:49, Andreas Zeidler wrote: hi framework team, we're quickly approaching the deadline for the first round of reviews. most PLIPs have already seen at least one review, but in total we're still at only 11 out of 24 necessary bundle reviews. we're also still one UI review short. so let's push a little harder and try to get those reviews done! :) in related matters... On Jan 19, 2009, at 4:36 PM, Andreas Zeidler wrote: On Jan 19, 2009, at 3:58 PM, Martijn Pieters wrote: Only 2 plips do not yet have a second reviewer assigned: #237 Minor i18n upgrades #243 Replace workflow history viewlet with content history viewlet Shall we tackle these ad hoc or will someone take these? perhaps let's get going with what's assigned and wait for any of the three missing PLIPs to potentially be submitted before taking care of the remaining review, shall we? i think it's time to assign those now, mostly so that nobody gets the impression they're already done or almost... ;) with a total of 12 PLIPs we get to review six each, so everybody needs to sign up for one more. i just did so (for #237) and would like to ask you to fill in the remaining slots today. also, raphael, i saw you sent some comments, but could you please update the overview page[*] as well, so we get a better, well, overview. :) cheers, andi [*] according to https://dev.plone.org/plone/wiki/PLIPTallies33 -- 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.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
Re: [Framework-Team] Concern about review progress
On 23.01.2009, at 10:07, Wichert Akkerman wrote: We are not almost a week into the two review period, and at this point two out of the required 22 reviews have been done, two PLIPs have not been assigned a second reviewer and none of PLIPs have received UI feedback. That lack of progress has me a bit worried. Please do not make this a last-minute review rush! let's revisit this on monday... i'm pretty sure, it won't be that bleak... Wichert. -- Wichert Akkerman wich...@wiggy.netIt 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
Re: [Framework-Team] PLIP Tallies
thanks wichert for your reminder and andi and raphael for your quick replies. i've taken this thread as opportunity to summarize the plips and who (so far) has taken on which review. i've included andi's and raphael's and added mine. since danny won't be able to do technical evaluations and since we also want to formally make sure, that UI concerns aren't overlooked i've added an extra column 'UI review'. @danny: could you mark which tickets you will review for UI impact? perhaps by making an X for those where you will and an explicit - for those which don't have any. i've linked to each ticket, because that's where the discussion will take place, the wiki page is only(!) meant as a one-stop-summary place. i'll try to update it with information as it comes in on the list, but please updated it yourself if you have anything that requires a change, thanks! here's the link: https://dev.plone.org/plone/wiki/PLIPTallies33 all the best, tom On 19.01.2009, at 14:39, Raphael Ritz wrote: Andreas Zeidler wrote: [..] · #126: Link type should automatically redirect when accessed directly · #234: Standardizing our use of INavigationRoot · #239: Adapterise the Extensible Indexable Object Wrapper · #240: Improve locking configurability · #247: Automate ZCML Loading for Plone Plug-ins Complementing this I'd like to go for #126: Link type should automatically redirect when accessed directly (because I did that one already - just not checked in yet) #237: Minor i18n upgrades #238: Disable inline editing by default #243: Replace workflow history viewlet with content history viewlet #246: View for rendering events as an iCalendar file 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] Re: NuPlone and Plone 3.2
On 13.01.2009, at 00:14, Hanno Schlichting wrote: Martin Aspeli wrote: The question now is how we deal with the release. We could: - Add Products.NuPlone as a dependency of the Plone egg. This would mean 'Plone' always comes with NuPlone, but there's no reason overt for the dependency. +1. Plone 3 ships with NuPlone in the same way it does with CMFEditions or any other package, we shouldn't change this in the 3.x series. Please introduce no special handling of it. +1 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] Re: NuPlone and Plone 3.2
On 04.01.2009, at 04:06, Martin Aspeli wrote: Matthew Wilkes wrote: On 3 Jan 2009, at 07:55, Graham Perrin wrote: In partial answer, http://dev.plone.org/plone/wiki/WheredItGoOnPloneTrunk http://dev.plone.org/plone/ticket/8805 http://dev.plone.org/plone/query?component=NuPlone+Themeorder=iddesc=1 http://dev.plone.org/plone/changeset/23493 Regards Graham Those are all Plone 4, not 3.2. I'm guessing NuPlone simply wasn't added as to the new Plone distribution after the bundle was abandoned. This is actually really bad, and I think it should block the 3.2 full release (i.e. with installers). for the record (and as the only 3.x fwt member chiming in on this so far): absolutely +1 for... Anyone who has a site with NuPlone installed will find that it breaks when they upgrade to 3.2. This is precisely the kind of thing we said we wouldn't do in the 3.x series, and in 3.2 in particular, which was supposed to be feature-identical, just re-packaged. ... precisely this reason ;) I did try to add Products.NuPlone as an egg manually, but that doesn't work either, because it has a spurious dependency on Products.CMFPlone. I think we need to: 1) Get a release of Products.NuPlone that works with 3.2 out to PyPI and dist.plone.org immediately. 2) Update the Plone egg to depend on it in a 3.2.1 release. +1 as this basically amounts to a bug fix 3) Base the installers and the release announcement on this version. i can't remember which version but wasn't there a plone version that skipped a minor version and went straight to the next higher one? at any rate i'd say this would be the most straight forward way to deal with this issue. but let's wait and see what wichert has to say on this, i'm just adding my $0.02 as fwt member. cheers, tom Wichert, what do you think? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP lifecycle
On 27.12.2008, at 23:28, Alexander Limi wrote: On Sat, 27 Dec 2008 09:56:23 -0800, Ross Patterson m...@rpatterson.net wrote: One way to keep these cross-checks lightweight might be to start with a statement of impact. There are code changes, for example, that have no UI impact. In such cases, it would be fast and more painless if a PLIP champion noted this. Someone from the UI team could then corroborate that the PLIP entails no UI impact and that would be the end of it. If there is an impact, then the PLIP champion would need to include full UI consideration for the impact in the PLIP. The UI team could then review both the statement of impact for accuracy and the UI consideration for sufficiency and completeness. The same would largely be true for the doc team with the exception that, IMO, all changes have a documentation impact even if it's only for developers and so there should be no option to declare no impact. This sounds like a good starting point. +1. +1 i particularly like the notion of using workflow states as 'reminders' to make sure aspects aren't missed. cheers, tom -- Alexander Limi · http://limi.net ___ 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: [Plone-developers] [Framework-Team] Re: Plone 4 Framework Team Selection List
On 18.12.2008, at 11:21, Martin Aspeli wrote: In particular, one of the things we'd discussed and would like to see more of, is a consultative approach where the framework team reviewer asks for review from people outside the team. Anyone who is motivated to contribute opinions will be heartily encouraged to do so, and it will be within the framework team's remit to actively solict those opinions. i really want to stress this point (if only by repeating it here...) 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. i can't imagine that any PLIP will be approved or denied without the evaluating fwt members having consulted with at least one of the 'usual UI suspects' beforehand. and as wichert himself already mentioned: all of those are currently very busy anyway, so i think it's best for everybody, if they are relieved from the 'leg work' and can focus on UI issues without having to follow all of the fwt discussions and proceedings. cheers, tom ___ 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
On 18.12.2008, at 11:34, Wichert Akkerman wrote: [...] things like user interface and documentation should be a full part of the process, absolutely and therefore should be reflected in the membership of the group which makes decisions based on those factors. i think that conclusion is the only part where we disagree. can we agree at least on that? ;-) cheers, tom Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Plone-developers mailing list plone-develop...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plone-developers ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Supported Plone Releases
my question is: how can the fwt decide this question if the key issue is the available man power and willingness to perform the actual support for a particular version. we can decide to support 2.5 but that alone doesn't make it so. personally, alec's statement would be enough for me to have 2.5 officially supported, but that's just a gut feeling based on my past experiences with the man ;-) it's certainly not an informed decision. how should or rather how could we possibly handle such a question? pondering in bristol, tom On 10.12.2008, at 21:57, Jon Stahl wrote: -Original Message- From: framework-team-boun...@lists.plone.org [mailto:framework-team- boun...@lists.plone.org] On Behalf Of Wichert Akkerman Sent: Wednesday, December 10, 2008 12:53 PM To: framework-team@lists.plone.org Subject: Re: [Framework-Team] Supported Plone Releases Previously Jon Stahl wrote: -Original Message- From: framework-team-boun...@lists.plone.org [mailto:framework-team- boun...@lists.plone.org] On Behalf Of Steve McMahon Sent: Wednesday, December 10, 2008 8:31 AM To: Framework Team Subject: Re: [Framework-Team] Supported Plone Releases Why bring this up on the framework team list? The framework team is not a governing body. Then, who is? I certainly think that if the framework team makes a decision on this, it would be widely respected and supported. I think that the PF Board would prefer not to make the decision, in order to continue the tradition of the board not governing development. And, I think the developer list is way too wide open. +1, I believe the board would vastly prefer not to set the precedent of making technical decisions about Plone. The Foundation protects and promotes; the community develops. :-) But this is not a technical decision at all. This is a decision about our ability and willpower to dedicate resources (skilled manpower) to accopmlish something. True enough. But I think there is a long-standing consensus that decisions regarding what software gets built and released should rest with the community, not the board. And the center of consensus in the community is the framework team, especially for decisions that require focused effort from a few highly skilled people. Like I said, I think the board is in generally in favor of this. But that's different from us deciding to continue making security fixes to 2.5.x. The community needs to decide to do that if feels it can/ should. And I think the community will tend to follow the framework team's lead here. :jon ___ 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 4 framework team nomination
On 11.11.2008, at 08:54, Wichert Akkerman wrote: I feel that I know Plone and Zope reasonably well by now, and I arlready have a passing familiarity with the framework and release processes. that made me LOL ;-) SCNR! and for the record: i'd love to have you on board ;-) 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
Re: [Framework-Team] Re: 4.x team nomination
On 07.11.2008, at 17:18, Andreas Zeidler wrote: On Nov 7, 2008, at 4:52 PM, Steve McMahon wrote: Jon and I can maintain that. Maybe next year we should use a Trac ticket. you could also use a trac ticket now (instead of the wiki page). that would probably make it easier to trac(k) things... %) -1 on the trac ticket. IMHO it would only make sense, if we used one ticket per nomination (with a common component). otherwise i'd recommend a (wiki) page. but in the end it's up to steve and jan, of course! cheers, tom 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
Re: [Framework-Team] Draft Call for Team Membership Applications
On 02.11.2008, at 12:17, Martijn Pieters wrote: On Sun, Nov 2, 2008 at 00:31, Steve McMahon [EMAIL PROTECTED] wrote: Got it. How's this? +1 from me :-) me, too. the new version does sound a bit more inviting than the old one, good feedback, martijn! cheers, tom -- Martijn Pieters ___ 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
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. 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
Re: [Framework-Team] Re: Draft Call for Team Membership Applications
On 31.10.2008, at 17:13, Steve McMahon wrote: We should get this out soon. If you'd like changes, please get them in right away. like i said, +1 from me ;-) go steve! Steve On Tue, Oct 28, 2008 at 9:10 AM, Steve McMahon [EMAIL PROTECTED] wrote: DRAFT Call for Plone 4.x Framework Team Members Would you like to help choose what goes into Plone 4? The Plone Framework team is now receiving applications for membership in the Plone 4 Framework Team. The Framework Team will be responsible for evaluating the PLone Improvement Proposals (PLIPS) for Plone 4.x. The team also nominates the release manager to the Plone Foundation Board, which does the hiring. PLIP evaluation consists of considering the benefits and risks associated with a PLIP and casting a reasoned and explained +/- 1 vote on each proposal. Framework Team members also follow PLIP implementation, and make recommendations to the Release Manager. Qualifications include: An awareness of community strategic discussions about Plone's development; Ability to make a long-term committment. Plone 4 will take some time, and the team will stay together to work on the entire 4.x series. A good understanding of Plone's architecture and UI: enough to weigh risks and benefits; Time to keep up with discussions on the Framework Team mailing lists; The ability to occasionally budget a significant amount of time for evaluating PLIPs in detail as feature-lock deadlines approach; The ability to work with SVN well enough to test PLIP integration and implementation for final evaluation; The personality to get along well in a flexible, give-and-take group process and to accept and support group decisions. New Framework Team members will be chosen by existing Framework Team members and involved FWT alumni. Considerations will include many criteria beyond the simply technical. The new team must be balanced in skills and likely to work well together. Please note something new: the Plone 3.x Framework Team will continue to work on enhancing Plone 3.x during the development of Plone 4 and possibly afterwards. If you're interested, please send an introductory note, explaining your interest and qualifications, to [EMAIL PROTECTED] Postings from non-subscribers are rejected, so if you're not a subscriber, send your message to [EMAIL PROTECTED] with a request for forwarding. -- 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] Draft Call for Team Membership Applications
thanks for the draft, steve! i wouldn't change anything, but unless my cold is still clogging up my brain too much, it doesn't seem to state the number of members the team will have, which might be worth mentioning to applicants. so perhaps we could stick that in there somewhere? cheers, tom On Oct 28, 2008, at 5:10 PM, Steve McMahon wrote: DRAFT Call for Plone 4.x Framework Team Members Would you like to help choose what goes into Plone 4? The Plone Framework team is now receiving applications for membership in the Plone 4 Framework Team. The Framework Team will be responsible for evaluating the PLone Improvement Proposals (PLIPS) for Plone 4.x. The team also nominates the release manager to the Plone Foundation Board, which does the hiring. PLIP evaluation consists of considering the benefits and risks associated with a PLIP and casting a reasoned and explained +/- 1 vote on each proposal. Framework Team members also follow PLIP implementation, and make recommendations to the Release Manager. Qualifications include: • An awareness of community strategic discussions about Plone's development; • Ability to make a long-term committment. Plone 4 will take some time, and the team will stay together to work on the entire 4.x series. • A good understanding of Plone's architecture and UI: enough to weigh risks and benefits; • Time to keep up with discussions on the Framework Team mailing lists; • The ability to occasionally budget a significant amount of time for evaluating PLIPs in detail as feature-lock deadlines approach; • The ability to work with SVN well enough to test PLIP integration and implementation for final evaluation; • The personality to get along well in a flexible, give-and-take group process and to accept and support group decisions. New Framework Team members will be chosen by existing Framework Team members and involved FWT alumni. Considerations will include many criteria beyond the simply technical. The new team must be balanced in skills and likely to work well together. Please note something new: the Plone 3.x Framework Team will continue to work on enhancing Plone 3.x during the development of Plone 4 and possibly afterwards. If you're interested, please send an introductory note, explaining your interest and qualifications, to [EMAIL PROTECTED] Postings from non-subscribers are rejected, so if you're not a subscriber, send your message to [EMAIL PROTECTED] with a request for forwarding. ___ 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 238: Disable inline editing by default
On Oct 28, 2008, at 10:20 PM, Danny Bloemendaal wrote: Well, I am all in favor of having the UI fixed. Perhaps some of the kss boys can do this. You need to have a hover event that shows a button next to the widget (button can styles using css into a pencil or something) and the click should trigger the edit mode. i may be wrong, of course, but i doubt anybody of the framework team would have voted for plip238 if we had such an implementation ;-) heck, if we had had a plip for the above scenario, that would have been voted in and wiggy probably would have never created #238. IOW: i'd rather disable a suboptimal implementation of a potentially cool feature (#238) than wait for an uncertain amount of time until we have a UI fix for that feature. I think that jeroen vloothuis could do this in an afternoon. we could ask him to help. please do! if he comes up with something, i'd like to propose that we treat his patch as an 'alternative implementation of #238', i.e. if we think of #238 as 'fixing inline editing' then jeroen's patch could still become part of plone 3.3 instead of sticking it into a new plip (which would then obviously have to wait until 3.4) just my $0.02, tom On 28 okt 2008, at 18:18, Wichert Akkerman wrote: Previously Alan Runyan wrote: On Tue, Oct 28, 2008 at 10:46 AM, Alec Mitchell [EMAIL PROTECTED] wrote: Is it really that much work to fix the ui for starting an edit? I think there are a lot of people who like this feature, but are frustrated by the UI. Disabling it does nothing to fix that though, it's just another regression to work around what many consider a real UI bug. I agree. Who owns this part of the UI? No part of the UI is 'owned'. If someone has a better implementation I'm all for that, but I don't have the right skillset to implement it. Until then this PLIP improves the currently situation quite a bit. 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 #197: Add FeedParser as external requirement
oops, this one slipped under my radar yesterday (as evidenced my steve's tally sheet). so for the record: +1 ;-) cheers, tom On Oct 26, 2008, at 6:03 PM, Martijn Pieters wrote: On Fri, Oct 3, 2008 at 23:59, Maurits van Rees [EMAIL PROTECTED] wrote: I propose plip 197 for Plone 3.3. Or really for 3.2 as it is a small packaging change which fits well in the overall theme of 3.2. I mentioned that on this list a few weeks ago without reactions. The plip is: #197: Add FeedParser as external requirement instead of shipping with it http://plone.org/products/plone/roadmap/197 I'll reconfirm my previous +1 -- Martijn Pieters ___ 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, here's the tally of my remaining plips: 126 +1 228 +1 236 -1 238 +1 239 +1 240 +1 241 +1 242 -1 243 +1 244 -1 247 +1 i've posted the votes and their motivations at the plips, but not on the list. cheers, tom On 28.10.2008, at 11:21, Tom Lazar wrote: yes, sorry for holding things up. i have seven plips to vote on and some office furniture to move, but i'm confident i'll get done within the next few hours while still making informed choices ;-) cheers, tom p.s. @steve: i'll send you a tally of my missing votes, so you should be able to update the list quite easily then. and thanks for the list! On Oct 28, 2008, at 10:27 AM, 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, 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] Comments on PLIP 244
On 28.10.2008, at 11:53, Ricardo Alves wrote: Hi framework team, I'm sorry I didnt' comment on the previous discussion about PLIP #244, but I wasn't subscribing this list. Anyway, I'd like to comment on some of the objections already posted in the PLIP page. About the usefulness of site-wide portlets, let me give an example: you have a static portlet assignment at a folder, and that portlet makes sense only in the context of that folder, so you want to block it in subfolders but keeping site-wide portlets visible (e.g. like news, review list, events, etc). Currently you can't do this, unless you manage to setup some weird combination using the other categories... Let me also make it clear that the idea here is not to break with existing functionality, neither with any concept. The idea of marking categories as not inherited by subfolders would be extremely useful. Currently, you need to block inheritance in all subfolders. Anyway, I'll be happy to reformulate this PLIP, or even split it into smaller ones, after some more discussion. i think the latter would be a good idea, because IMHO there are some good ideas in the plip that are worth implementing in their own right, i.e. point #3: Improve the portlet management screen to show all portlets that can be shown, so users are able to see what's going to be blocked with a category. i'd vote that +1 any time. it would also open the door for blocking portlets not per category (the whole category idea is misguided IMHO in regard to portlets) but per instance. (that might be a separate plip, too) just my $0.02, tom Thanks, Ricardo ___ 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] Kicking off Plone 4: Release Manager candidate
On 28.10.2008, at 13:03, Alan Runyan wrote: +1 to Hanno/Martin being Plone 4 release manager/communicator same here! tom -- Alan Runyan Enfold Systems, Inc. http://www.enfoldsystems.com/ phone: +1.713.942.2377x111 fax: +1.832.201.8856 ___ 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
having looked at the diff (and having witnessed its creation on the plane ;-) i'd hereby like to +1 the plip, as well as the implementation. it's a small, useful enhancement and i would like to keep it small. let's keep refactoring ATCT for another day and plip ;-) cheers, tom On 21.10.2008, at 16:48, Andreas Zeidler wrote: On 20.10.2008, at 19:21, Alec Mitchell [EMAIL PROTECTED] wrote: On Mon, Oct 20, 2008 at 9:51 AM, David Glick [EMAIL PROTECTED] wrote: Why is a calendar support mixin used, instead of adapting to ICalendarSupport? The latter would make it easier to also implement calendar support for non-AT content. that's because all that code already existed in atct. i've merely added a single view putting a few pieces together -- please see the diffs in that branch. so the question is rather why atct is using mixins instead of adapters!? ;) apart from that, i'd agree that the latter would make things more flexible, of course. No mixins please. +1, but like i said, i didn't put it in nor was i about to take over maintenance of atct... ;) andi ___ 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] Notes from Framework Team Meeting in DC
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? 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
Re: [Framework-Team] PLIP 244: Portlet management improvements
+1 from me The way I understand the proposed changes they are not breaking backwards compatibility, but simply make it easier to achieve already existing functionality. also +1 on the idea of making portlet assignments browser layer dependant. that's a feature i often find a need for. cheers, tom On 16.10.2008, at 17:35, 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 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 -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 244: Portlet management improvements
On 17.10.2008, at 00:39, Martin Aspeli wrote: I used to think that way, I'm not so sure anymore. Speaking to people about this over the past few months, I've come to realise that our model of thinking that the site root is the parent of all content from which things like portlets can inherit if they need to be site-wide is not how people tend to think about it. I think to most people, the root is the front page and is just a page. You may want some portlets on the front page, or you may want some portlets that are global and show up (almost) everywhere. In our current model, the workaround is that you have to be careful to assign portlets to the root and then not block them unduly. This gets unnatural, especially if you have deep or complex content hierarchies. FWIW i can directly attest to that from an ongoing project. i.e. i have some users feeling pain that would (at least partially) go away if we had this plip already. $0.02, tom ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Meeting up in DC
On Oct 6, 2008, at 9:26 AM, Steve McMahon wrote: I'll take that as a nomination for Fado. Fado it is! Shall we aim for 7pm? well, there's the dinner meeting at 6pm at the ethipian restaurant[1] and for 8pm at fados. my personal plan was to meet folks at 6pm at the restaurant (Meskerem 2434 18th St NW) and then head over to fados. so shall we say 8pm at fados? i'd like to go to both meetings... cheers, tom [1] http://www.openplans.org/projects/plone-conference-2008-dc/dinner-and-drinks My cell is +1 530.219.1431 On Mon, Oct 6, 2008 at 4:40 AM, Danny Bloemendaal [EMAIL PROTECTED] wrote: Is that on 808 7th St NW, Washington? http://maps.google.com/maps?f=qhl=engeocode=q=fado+pub,+Washington,+DC+20037ie=UTF8ll=38.900919,-77.021027spn=0.018269,0.043473z=15 And what time exactly? On 3 okt 2008, at 17:17, Steve McMahon wrote: Hi Framework Team, I asked our conference social planner, JoAnna Springsteen, for possibilities for a dinner spot where we could meet up Monday night and actually hear one another. Here are her suggestions. If one or more of these spots sound particularly good or bad, let me or the list know. Sometime in the next couple of days, I'll make an executive decision on our behalf. Steve Hmmm. Well Monday night we're going to go to Fado. It's a large pub that serves food. They're having a trivia quiz night and I'm trying to get a Team Plone together. If you guys ate there we could meet up with you later. Not sure if the food is great or if it's all that quite though. Science Club would be good but it's where we're going for our official pre-conf social Wednesday night, plus it has an all vegetarian menu which may not appeal to all. DC locals say Granville Moore's is supposed to be great both food and beer wise but it's not close to the metro. Sushi Taro would be good but you'd definitely have to make reservations to get in with that many people. Central is supposed to be great and it's near the conference location but it's a bit higher end and it's another place you'd have to make reservations. I liked the Brickskeller when we went there. It's a bit of a walk from the dupont circle metro but it has a huge beer menu and serves food. It's not a huge place but I could just see a group of geeks huddled in the corner here debating something. The locals aren't super impressed by it but I dug it. Again, you might want to check and see if they can accommodate a bigger group for dinner. I know the Capitol Lounge can handle big groups but I'm not sure that the food or atmosphere is a particular draw. The prices and food are both supposed to be decent so it probably won't wow you but it could be a safe bet for you to just walk in and get seated in a reasonable amount of time. -- 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 -- 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] Meeting up in DC
On Oct 6, 2008, at 1:21 PM, Danny Bloemendaal wrote: sounds good.. what's this dinner meeting (or did I miss something)? the latter ;-) here's the link that i posted in my previous message: [1] http://www.openplans.org/projects/plone-conference-2008-dc/dinner-and-drinks see the entry for monday: Monday, October 6th, 6pm, Ethiopian dinner at Meskerem 2434 18th St NW. so, see y'all there then! cheers, tom On 6 okt 2008, at 11:36, Tom Lazar wrote: On Oct 6, 2008, at 9:26 AM, Steve McMahon wrote: I'll take that as a nomination for Fado. Fado it is! Shall we aim for 7pm? well, there's the dinner meeting at 6pm at the ethipian restaurant[1] and for 8pm at fados. my personal plan was to meet folks at 6pm at the restaurant (Meskerem 2434 18th St NW) and then head over to fados. so shall we say 8pm at fados? i'd like to go to both meetings... cheers, tom [1] http://www.openplans.org/projects/plone-conference-2008-dc/dinner-and-drinks My cell is +1 530.219.1431 On Mon, Oct 6, 2008 at 4:40 AM, Danny Bloemendaal [EMAIL PROTECTED] wrote: Is that on 808 7th St NW, Washington? http://maps.google.com/maps?f=qhl=engeocode=q=fado+pub,+Washington,+DC+20037ie=UTF8ll=38.900919,-77.021027spn=0.018269,0.043473z=15 And what time exactly? On 3 okt 2008, at 17:17, Steve McMahon wrote: Hi Framework Team, I asked our conference social planner, JoAnna Springsteen, for possibilities for a dinner spot where we could meet up Monday night and actually hear one another. Here are her suggestions. If one or more of these spots sound particularly good or bad, let me or the list know. Sometime in the next couple of days, I'll make an executive decision on our behalf. Steve Hmmm. Well Monday night we're going to go to Fado. It's a large pub that serves food. They're having a trivia quiz night and I'm trying to get a Team Plone together. If you guys ate there we could meet up with you later. Not sure if the food is great or if it's all that quite though. Science Club would be good but it's where we're going for our official pre-conf social Wednesday night, plus it has an all vegetarian menu which may not appeal to all. DC locals say Granville Moore's is supposed to be great both food and beer wise but it's not close to the metro. Sushi Taro would be good but you'd definitely have to make reservations to get in with that many people. Central is supposed to be great and it's near the conference location but it's a bit higher end and it's another place you'd have to make reservations. I liked the Brickskeller when we went there. It's a bit of a walk from the dupont circle metro but it has a huge beer menu and serves food. It's not a huge place but I could just see a group of geeks huddled in the corner here debating something. The locals aren't super impressed by it but I dug it. Again, you might want to check and see if they can accommodate a bigger group for dinner. I know the Capitol Lounge can handle big groups but I'm not sure that the food or atmosphere is a particular draw. The prices and food are both supposed to be decent so it probably won't wow you but it could be a safe bet for you to just walk in and get seated in a reasonable amount of time. -- 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 -- 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 #187: Working out-of-the-box WebDAV
On Oct 3, 2008, at 2:24 PM, Sidnei da Silva wrote: I would like to propose PLIP #187 for Plone 3.3. feature wise i think we all agree that it's a very desirable feature. IMHO i think it's a perfect match for 3.3 as it represents a backend improvement that doesn't affect API or UI. so i'm +1 on this. cheers, tom I already have pretty much all the work done, in a branch. It just needs polishing and merging. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 3.2 and 3.3 planning
if any of my previous conferences and sprints are an indicator, i just *know* that i won't be doing any actual fwt review work while in DC. but that's not important. review work is 'fleissarbeit' to use a nice german term here and can easily be done alone, whenever one can find some time. i'd like to use the time at the conference to discuss actual ideas/plips and to brainstorm the future fwt process, so i have no problem with a post-conference plip deadline (although, it shouldn't be too far after the conference as to not remove momentum from the ideas/plips that have been fleshed out during the conference. so, i guess, i'm +1 on wichert's deadline of one week after the conference. in fact, i think it's pretty much perfect... just my $0.02 tom (who does indeed read the fwt via plain old email and thus sometimes misses any action on the list for a few days...) (i have a separate IMAP account for list traffic that i don't check as regularly as my personal account) On 14.09.2008, at 13:32, Andreas Zeidler wrote: On Sun, 14 Sep 2008 13:16:40 +0200, Martin Aspeli [EMAIL PROTECTED] wrote: I'm not really interested in labouring this further. how about --- as a compromise --- set the deadline for turning in PLIPs on friday october 10th, i.e. the last day of the conference? the fwt will be busy discussing their processes during the first couple of days anyway (hopefully). at least personally i don't expect to have time to review PLIPs while the conf is still running. that'll change once the sprint starts, though. i haven't really decided what i'm gonna work on, so i might as well set some time to review and discuss PLIPs with the other members and hopefully also with their authors. In the future, I think it'd be good if we adopted a slightly more consultative approach to setting deadlines for the process. +1 If the FWT were forced to be more actively involved in the planning and setting of deadlienes in the first place (How many have actually chimed into this thread? Only Andreas, I think...), then they may also feel more responsible for meeting those deadlines. +1 as well. and, as a side note, i'm not sure if all members are reading the fwt list as mail or via a news reader, but i suspect some of them do the latter and might not have noticed the discussion yet. an easy fix for that might be to actually cc all members directly on mails like wichert's announcement. the schedule and deadlines will affect the fwt members directly, so we should make sure they know about them asap. 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.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 ___ 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
On 12.09.2008, at 10:22, Andreas Zeidler wrote: On Sep 12, 2008, at 4:16 AM, Jon Stahl wrote: I'd love to join you all, if you're willing to let an interested bystander horn in. ;-) please do! :) absolutely! 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Re: Framework Team Page Needs Updating
just for the record: the way i recall things, all current members pretty much agreed from the start to follow up until 3.2. now it seems, that that, which was originally (albeit vaguely) planned for 3.2 will be split up into 3.2 and 3.3. i'm certainly happy to serve on the board until 3.3 and i'm looking forward to our meeting in dc! cheers, tom On 21.08.2008, at 22:27, Andreas Zeidler wrote: On Aug 21, 2008, at 2:31 AM, Alexander Limi wrote: On Wed, 20 Aug 2008 15:12:53 -0700, Andreas Zeidler [EMAIL PROTECTED] wrote: hmm, i guess i must have somehow missed the discussion that lead to that consensus (this is not meant to sound cynical or anything, btw). there was some talk right after 3.1, and of course there were plans to write things down in order to improve the process for the future. i might very well have missed parts of any more recent discussion, but as a member of the (currently still active) 3.1 team, i'm wondering why i don't really seem to know about this consensus. or was it just an effective one, i.e. one that sort of came up because the discussion was never really finished? That's what consensus means, at least in casual English. hmm, i guess the meaning that had been stuck in my head is slightly different, but well... :) To be more precise, there wasn't a we will do it this way, period decision, but most people seemed to think it was a good idea, and I didn't see anyone express strong opinions otherwise. i did express some concerns, albeit not strong and not on the list (or otherwise online) either. anyway, i think we should at least ask the current members if they're up for it, no? i for one would happily help reviewing PLIPs again, but i won't be spokesperson again nor do any of the other housekeeping, like poking people, writing summaries and status updates etc. that work caused quite a bit of stress and irritation, simply since it took a significant amount of extra time. i still think we should have an extra team member for this, i.e. organizing the team and the reviews and making sure things happen in time, at least more or less... 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.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 mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Resource Registries improvements PLIP
+1 from me, too. i'm wondering though, if there could be a more elegant solution to the SSL issue. i.e rather than requiring two registry entries with their own https-conditions, why not make that decision at render time i.e. in the template? (i.e. Products/ResourceRegistries/www/ jscomposition.zpt if i'm not mistaken) although, i could imagine, that that could be a case of 'trying to be too clever'. i.e. what if the external resource simply has no https hosting? any thoughts on that? cheers, tom On 05.08.2008, at 00:51, 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 ___ 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] availability over the next 5 months
hi wiggy et. al.! i'll be on vacation (and entirely offline!) from july 26th through to august 11th. other than that i will try my best to help get 3.2 out the door... bring it on! ;-) cheers, tom On 29.06.2008, at 21:43, Wichert Akkerman wrote: 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). 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
Re: [Framework-Team] Re: [Plone-developers] moving description to aviewlet
On 20.05.2008, at 06:53, Jon Stahl wrote: I agree that we should have a stronger opinion about this in Plone 4.0. Personally, I lean towards making it pure-metatadat and adding a lead-in content field. +1 FWIW, this is exactly what we are doing here for a current (newspaper) project and (incidentally) is the exact use-case that the journalists involved in the project came up with without any knowledge of this issue here on the list. i.e. they wanted a description field for metadata (i.e. search engines) and an explicit lead-in field for the articles. just my $0.02, tom ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: WebDAV changes
On 24.02.2008, at 21:49, George Lee wrote: Tom Lazar [EMAIL PROTECTED] writes: for the record: the front-page issue mentioned by wiggy did *not* occur in my testing of the bundle itself, which suggests that it is perhaps caused by some side-effect of previous merges. and certainly outside the scope of the framework-team testing... (not that it actually matters now, though) Or perhaps an issue with removing Calendaring, keeping Lime, and keeping the CMFPlone changes (for instance, a broken import Calendaring step in CMFPlone that it doesn't understand without Calendaring?) -- not with actually having all of them together. ah, i wasn't aware that the bundle had only been partially merged by wiggy. your explanation certainly makes sense. My framework-team questions is more about to egg or not to egg and unneeded code, whether that should have been noted. I think people's suggestions of a better framework team process; and communicating more clearly when things need to be reverted, by whom, and why -- make sense. Peace, George ___ 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] WebDAV changes, tests and process improvements
On 27.02.2008, at 17:43, Andreas Zeidler wrote: On Feb 27, 2008, at 1:17 PM, Graham Perrin wrote: On 27 Feb 2008, at 10:44, [EMAIL PROTECTED] wrote: With this lack of general knowledge, I didn't (don't) know ... My apologies! I just noticed http://dev.plone.org/plone/ticket/7732#comment:2 reference to REVIEW-NOTES.txt which explains the presence of Calendaring and Lime. it's kinda funny how many things came together to prevent this from being brought up... aside from the late review and the complexity etc, this was also the only PLIP (except for 209 which didn't have a bundle) where the notes of the reviewers were only posted to the ticket, but not added to REVIEW-NOTES.txt like everywhere else. actually, that's not true. both raphael and myself added our notes to the bundle: http://dev.plone.org/plone/changeset/19366 http://dev.plone.org/plone/changeset/19376 the latter would probably have helped to notice the lack of review on those new packages at a much earlier state, at least for me i think... apparently not ;-) 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.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] Re: WebDAV changes
as a member of the framework team (and as somebody who co-reviewed sidnei's bundle) i feel the need to speak up. sidnei, i understand your frustration but please consider the following: * your bundle was one of the most complex ones submitted (certainly the one with the largest impact) * each reviewer cautioned against unconditional acceptance of this plip due to the fact that it was difficult to review * each reviewer pointed out several issues that require addressing, which haven't been addressed yet. * each reviewer came to the conclusion that the current status of the bundle does not satisfy the 'OOTB working webdav' claim of the plip * instead we said, let's include the bundle for the benefits that it brings and then finish it for 3.2 if wiggy, as release manager, now finds that there are bugs in the code that actually make things *worse* than before i'm afraid i have to agree with his decision. this is certainly nothing personal against you. i'm only pointing this out, because it appears to me that you are disgruntled. you are free to blame the framework team, including myself, for not having caught the bugs that wiggy now has, but then again, there really was no clear testcase against which to test your bundle (you certainly didn't provide anything along those lines) and eventhough each reviewer approached it from a different angle it just proved not to be enough. personally, i'm glad the bugs were found *now*, i.e. before the betas and i can only urge you to hang in there for 3.2; i would like to offer to review the bundle again for 3.2 (which we will start working on pretty much straight away after 3.1 is released) and to work more closely with you. i think the work you're doing for webdav is important and i have a personal interest to have working webdav. i hope this can ease things a bit for you. all the best, tom On 24.02.2008, at 18:19, Sidnei da Silva wrote: On Sun, Feb 24, 2008 at 1:04 PM, Wichert Akkerman [EMAIL PROTECTED] wrote: I've just reverted the WebDAV changes from Sidnei after playing a bit with them. What?!? I did this for two reasons: Hanno had some very good remarks that need to be addressed And there's nothing that prevents them from being addressed other than time? I tested the 3.1 tree with just Calendaring removed. Some testing there quickly revealed that there are other things broken: the default frontpage for a Plone site is no longer created properly this made me feel that at this moment the implementation of this PLIP is note quite mature enough. How does that relate to the changes I made? Please provide more details. We have too much happening in the 3.1 tree at the moment to work on it there, so this should mature a bit more before we merge it again. I find that completely unfair. You have not provided any clear reason why it should be reverted. I can't see from your email how the frontpage is related to WebDAV changes. I am quickly losing any interest I had in getting those changes merged. At best, you should have asked *me* to revert the changes. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] The final(?) verdict
On 20.02.2008, at 09:35, Wichert Akkerman wrote: Thanks very much for the report Raphael. I'm going to treat this as the official recommendatation of the framework team. and so will i. some of the +3 and +4 would actually need to be increased by one, namely my own vote, which i chose to cast 'blanket style', which i admit was not a good idea (and just being too lazy, shame on me!). seeing that there is no area of dispute i think it would be pointless for me now to go through all of them and still cast my vote but i do want to at least take this opportunity and promise to cast my votes explicitly for *all* plips for 3.2 ;-) i also want to thank andi for being a kick-ass (literally, sometimes!) framework spokesperson and raphael for stepping in. cheers, tom Some quick comments: Previously Raphael Ritz wrote: 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? I talked with Florian and Danny yesterday and tried it myself as well: at this moment USW is not ready yet so it'll be deferred. 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. 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) Must be fixed - this can break export on sites where export currently works. 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) Must be fixed - this can break export on sites where export currently works. 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) SteveM contaced me about that yesterday and we agreed that the behaviour in Plone will change here: if it detects that it is run from a buildout (which we can easily see from the path) we will direct users to Martin's third party add-on tutorial on plone.org. 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 From what I've seen so far those glitches have been correctly ported from the current non-jquery codebase, so they should not prevent a merge. 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] Ticket #7816 Improve Framework Team process
FYI, limi has created a ticket for improving the framework team process -- but s3kritly, it seems ;-). thanks to raphael for the pointer, though. perhaps others would like add themselves to the cc: list: https://dev.plone.org/plone/ticket/7816 cheers, tom ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] The final(?) verdict
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* 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] Ticket #7816 Improve Framework Team process
On 20.02.2008, at 16:29, Andreas Zeidler wrote: On Feb 20, 2008, at 3:21 PM, Tom Lazar wrote: FYI, limi has created a ticket for improving the framework team process -- but s3kritly, it seems ;-). that's a PSPS focus area ticket, i.e. one of the things identified at the summit and assigned to be championed by someone, in this case matt. ah, i missed that bit. so i wouldn't exactly call this secret — not with the amount of public announcement and discussion we currently see on plone-dev anyway... kinda seems more likely you're currently not following any of that, doesn't it? ;) guilty as charged (seriously, i find it almost insane how much momentum plone is experiencing at the moment... i really have trouble keeping up with it all... but then again: what a truly great problem to have ;-) 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.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] The final(?) verdict
On Feb 20, 2008, at 9:45 PM, Danny Bloemendaal wrote: Hi all, sorry for the late reply, had a busy day. Anyway, thanks again Raphael for your wrap up. On 20 feb 2008, at 15:48, Raphael Ritz wrote: 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 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! 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
Re: [Framework-Team] Testing for PLIP 209: Unified Installer Plus Buildout
On 18.02.2008, at 00:20, Steve McMahon wrote: Tom, The obvious just occurred to me: I'll be you're trying this from an SVN checkout. obvious to you (well, and everybody else, so it seems...) you see, that tidbit isn't mentioned in the README that's part of the svn nor at the actual plip[1], although the latter does refer to a tarball in the deliverables section and once more in the progress log. i guess it's simply due to the fact that prior to this plip review i have never used any of the unified installers and hence probably just missed that it's all about the tarball. The svn does not include all the many megabytes of third-party tarballs required to run the installer. (Wiggy has very reasonably requested that they be kept out of svn.) So, to test the new UN+BO, you'll need to download it from Launchpad: https://launchpad.net/plone/3.0/3.0.5/+download/Plone-3.0.5-UnifiedInstallerBuildout-beta2.tar.gz i downloaded this and everything worked fine from then on. i created a zeo setup with its own python and libjpeg(!). this is great stuff. i shall be using this for my own client work from now on, as the buildouts i have so far used were very nice for the client but still needed to be accompanied by a lengthy README as how to install the dependencies. beyond this particular installation i haven't done any further testing, but as mentioned, others have done that already, so all i can say is: +1 ;-) (BTW, I expect to be doing a version for Plone 3.0.6 early next week. It will include the fix for the relative path issue discovered by Raphael.) Steve On 2/17/08, Steve McMahon [EMAIL PROTECTED] wrote: Hi Tom, I'm at a loss as to what's not working here. That message should only show up if the helper_scripts or packages directories aren't present or aren't searchable. I wonder if we've got an odd variety of sh or some extra ACL permissions at work. What's your platform? By the way, the same component execution code is in the existing (non-buildout) installer. So there's a good chance that it also wouldn't work for you. Steve On 2/17/08, Tom Lazar [EMAIL PROTECTED] wrote: hi graham, thanks for the hint, however, i had tried that already myself and it didn't work, either. sudo sh ./install.sh --target=/opt/zope/instances/209 -- user=tomster -- instance=plip209 zeo ZEO Cluster Install selected This install script must be run within the installer's top directory. That directory should contain packages and helper_scripts subdirectories. so, for me the plip is not functional and i can't give it a +1 in this state. i'm sure it's just something trivial, but the point is that it's supposed to be *easy* for the end user lateron, and they will likely stumble over the same issues. tom On Feb 16, 2008, at 3:54 PM, Graham Perrin wrote: On 16 Feb 2008, at 11:55, Tom Lazar wrote: sudo sh install.sh --target=/opt/zope/instances/209 --user=tomster --instance=plip209 zeo Where you have sudo sh install.sh should that be, sudo sh ./install.sh This install script must be run within the installer's top directory. I received that message once, when I tried specifying the path from my working directory to install.sh Regards Graham -- __ Steve McMahon Reid-McMahon, LLC [EMAIL PROTECTED] [EMAIL PROTECTED] -- __ 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
Re: [Framework-Team] Suggestion for more a better streamlined process?
On 18.02.2008, at 11:41, Martin Aspeli wrote: Thanks Danny, There have been various good ideas about how to improve the process. I think right now we need to focus on finishing the release, but we should definitely capture the lessons learned afterwards and write up a clearer process, including some guidance on appropriate tools. i second this. let's first get this baby (3.1) out the door! ;-) i, too, have (of course) some ideas that have arisen over the past few weeks and will write them up... *after* 3.1 is finished... Matt Bowen has volunteered to help drive this, and Andreas and others (including me) want to help here as well. +1 me, too. i also want to definitley stay on for 3.2, as well, which will then have a much more streamlined process. but for now i will keep my energies on getting 3.1 done. speaking of which... plip187 is still beckoning ;) cheers, tom Martin On 18/02/2008, Danny Bloemendaal [EMAIL PROTECTED] wrote: Hi folks, I have been thinking (yes, I try that occasionally) and I must say that we really need some sort of better tooling for the entire review process. It is all too scattered if you ask me. I really don't know where I have to find what I need to know for reviewing. Plone.org, track, svn, plone-devevelopers@, framework-team@ etc etc, I need one place where I can find everything there is to know: * which releases are there and * which plips do we have to review for this release * which deadlines are there * who are the reviewers (ok, not so necessary but for completeness...) * discussion threads for each plip during the review in ONE PLACE * status overview of the review process * instructions per plip on how to checkout, review, what to look for etc * It may sound like 'cursing in the church' (pardon my dutch) but many of the modern forum tools out there already allow you to do all this. You could set it up where each release is a forum with some sticky posts listing the plips with urls to the plip definition and threads for each plip in the release. Then each plip can have it's own discussion. We could add a few sticky posts with process status and other information needed for each release and each plip. Given the low amount of plips per release I think that a forum isn't so bad. The problem with Trac is that you always have to do queries to get to the data you need and you never know if you haven't missed anything. I always have a feeling of drowning in Trac-like tools. It may seem strange to suggest this but at least we don't have to re- invent something ourselves. It's easy to set up and I even think that ploneboard should support this from the start. I certainly would volunteer (with some help) to set up such a board or... when people have even better ideas, to help implement that. In any way, we have to improve on this and I really don't think it is hard to do :)) Danny. ___ 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
hi graham, thanks for the hint, however, i had tried that already myself and it didn't work, either. sudo sh ./install.sh --target=/opt/zope/instances/209 --user=tomster -- instance=plip209 zeo ZEO Cluster Install selected This install script must be run within the installer's top directory. That directory should contain packages and helper_scripts subdirectories. so, for me the plip is not functional and i can't give it a +1 in this state. i'm sure it's just something trivial, but the point is that it's supposed to be *easy* for the end user lateron, and they will likely stumble over the same issues. tom On Feb 16, 2008, at 3:54 PM, Graham Perrin wrote: On 16 Feb 2008, at 11:55, Tom Lazar wrote: sudo sh install.sh --target=/opt/zope/instances/209 --user=tomster --instance=plip209 zeo Where you have sudo sh install.sh should that be, sudo sh ./install.sh This install script must be run within the installer's top directory. I received that message once, when I tried specifying the path from my working directory to install.sh Regards Graham ___ 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
judging by andi's summary and the recent reviews we currently have the following plips that have only one review (there aren't any left, that have been submitted and have not been reviewed, so at least we've got that covered...) #187: Working Out-of-the-box WebDAV raphael #202: Support inline validation and editing [...] raphael #207: Allow Custom Portlet Managers andi #208: Adapter-Based Local Role Lookup andi #212: Use jQuery Javascript Library tom #215: Include new KSS versions tom #217: Use Adaptation for Workflow Assignmentandi #220: Improve browser layer support andi also, we now would need to read all the remaining review notes and cast our votes based on them. does that mean, we need to check out all plips because not all review notes have been posted to the PLIPs in the PSC. where do we collect the votes? again in the PSC or here on the list? based on my own reviews and those that i have read, cast a +1 on the following #184: Include more/improved portletsmartijn, raphael #202: Support inline validation and editing [...] raphael #203: Manage portlet assignments with GenericSetup martijn, raphael #204: Manage content rules using GenericSetup martijn, raphael #212: Use jQuery Javascript Library tom #213: Prepare for better Syndicationandi, tom #215: Include new KSS versions ?? (+tom) #220: Improve browser layer support andi #224: CSRF protection framework raphael (+andi) tonight i will look into the remaining ones and cast my vote accordingly. gotta run now. cheers, tom On Feb 16, 2008, at 1:16 AM, Andreas Zeidler wrote: On Feb 16, 2008, at 1:10 AM, Andreas Zeidler wrote: 1. could someone from the team _please_ step up and go through the list of PLIPs[1] tomorrow, checking which one have already been reviewed twice and either close them (in case of no pending issues) or make sure they're assigned to the respective author _and_ notify them by email just to make sure? i forgot to attach my little review status notes, perhaps that helps somewhat... cheers, andi review-status.txt -- 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] my review status
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. 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
Re: [Framework-Team] Testing for PLIP 209: Unified Installer Plus Buildout
i just realized, that steve might not get notifications from trac, so i hereby post my previous comment: after checking out : and issueing the following command: sudo sh install.sh --target=/opt/zope/instances/209 --user=tomster -- instance=plip209 zeo i get the following output: 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
[Framework-Team] my review status
just FYI since the review deadline is *today*, as of now i have reviewed and submitted the following plips: #195: Support product dependencies #212: Use jQuery Javascript Library #213: Prepare for better Syndication #215: Include new KSS versions the following is still in progress, as i couldn't get it to work (have posted feedback to list, steve and trac): #209: Add buildout to Unified Installer the last remaining one i will do later tonight (after the kids are in bed...) #201: Improve the UberSelectionWidget UI cheers, tom ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP #215: Include new KSS versions
hi everybody, here's my review of the bundle: review by tomster manual click tests == i applied the same manual click tests as for plip 212 (jquery), i.e. performed with fresh checkout, new instance with Plone Default skin. Using Firefox 2.0.0.12, Safari Version 3.0.4 (5523.15) and Windows Internet Explorer 6.0 (7.0 not available at review time due to lack of IE7 compatible Windows OS). Features and areas covered: * livesearch, portal calendar pagination, external links, inline editing, folder_contents reordering: no problems encountered, everything worked as expected. except, that the following error would be visible in firebug from time to time: opera_is_broken is not defined KupuSelectionTestCase()test_kupuhelpers (line 264) registerTestCase(KupuSelectionTestCase(), kupu)unittestUtilities... (line 9) [Break on this error] opera_is_broken(this, 'testParentElementImg'); however, this has been fixed in the course of plip212 by fschulze and is expected to disappear when both plips are merged. * document_actions: changing the workflow of an item triggered reloading of the page, which didn't use to be the case with previous versions. cut, copy and paste worked as expected. automated tests === running (presumably) all unit tests by issuing ./bin/instance test -s plone resulted in (only) one failure, namely in src/plone.app.workflow/plone/ app/workflow/tests/onestateworkflow.txt, line 117, in onestateworkflow.txt running the JS testsuite by calling $portal_url/test_ecmascripts on all three browsers produced no errors. running all kss.core tests by creating a KSS DemoContent object named 'demo' as described in the bundle notes showed that all tests pass. running the selenium tests with a `Zuite` object produced one failure and one 'incomplete', however i was not able to locate the failing test (even after a second run with the log window enabled, it just displayed 'error: false'), the instance.log displayed this: 2008-02-16 14:03:38 ERROR Zope.SiteErrorLog http://localhost:8080/demo/errTest/errTest 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 wrapper, line 5, in wrapper Module kss.core.actionwrapper, line 238, in apply Module kss.core.plugins.core.demo.demoview, line 156, in errTest Exception: We have an error here. verdict === despite the test failures i still vote for inclusion of this bundle as it represents a major clean up that should make KSS users' life a lot easier and thus perfectly fits the scope of the 3.1 release (polishes under the hood) On Jan 31, 2008, at 5:22 PM, Tom Lazar wrote: a big 'thank you' from me, too. i think the changes you mentioned are well worth including in 3.1 and i will definitely review this plip, too (also it fits quite nicely with florian's jquery plip) again, i will try to fit this in before the 12th (but no promises...) cheers, tom On 30.01.2008, at 21:02, Raphael Ritz wrote: Balazs Ree wrote: Finally... (drum roll): https://svn.plone.org/svn/plone/review/plip215-new-kss-version Thanks Balazs, this is great news. Irrespective of the delay I'll definitively take a look and comment on it. 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Re: PLIP 212 ready for review
On Feb 14, 2008, at 1:57 PM, Florian Schulze wrote:
On Wed, 13 Feb 2008 20:20:40 +0100, Tom Lazar [EMAIL PROTECTED]
wrote:
On 12.02.2008, at 23:41, Florian Schulze wrote:
instead i got the following error in jquery.js (via firebug)
a is not a function
[Break on this error] eval(function(p,a,c,k,e,r){e=function(c)
{return(ca?'':e(parseInt(c/a)))+((c=c%a...
Note: this error remained, even after replacing the shipping
jquery version 1.2.2 with the meanwhile current version 1.2.3
This looks like a syntax error in that file. I will look into it.
well, since it's the jquery.js file itself, i kind of doubt it
(which also prompted me to try out the 1.2.3 version) but hey!
you're the expert ;-)
This is either another syntax error, or some issue with the KSS
interaction.
you tell me ;-)
I can't reproduce any of these issues. I tried my exisiting buildout
and I made a fresh co of the buildout and ran buildout with the
option to get the newest version of everything.
well, given the fact that i indeed *can* reproduce these, chances are,
others will, too.
watching the process of publishing or retracting a page shows clearly,
that the entire page is reloaded. i can see for an instance that a
ressource named content_status_modify is called but immediately after
that the whole page is reloaded.
as for item actions, for instance using the copy command indeed does
*not* reload the entire page and works as advertised (not sure why i
didn't catch that the first time round, i could have sworn it reloaded
the page, too), but upon execution i get the following two JS errors:
Unhandled error during command execution: ReferenceError:
initializeMenus is not defined++resource++kukit... (line 144)
initializeMenus is not defined
(no name)(Object node=ul#contentActionMenus parms=Object)++resource+
+kukit... (line 7793)
executeClientAction(bindActionMenus)++resource++kukit... (line 866)
execute(Object node=ul#contentActionMenus parms=Object)++resource+
+kukit... (line 2568)
execute(Object node=ul#contentActionMenus parms=Object)++resource+
+kukit... (line 2389)
EventBinder_triggerEvent(load, Object node=ul#contentActionMenus
parms=Object)++resource++kukit... (line 3897)
func_to_bind(undefined)++resource++kukit... (line 981)
execute()++resource++kukit... (line 516)
addPre(function(), Setup of events for nodes subtrees [ul], [dt],
[dd])++resource++kukit... (line 497)
doSetupEvents([\n, ul#contentActionMenus, dt, 1 more...])++resource+
+kukit... (line 1271)
finishSetupEventsCollection()++resource++kukit... (line 1241)
executeCommands(Object node=a#copy.actionicon-object_buttons-copy)+
+resource++kukit... (line 5833)
processResult(XMLHttpRequest channel=[xpconnect wrapped nsIChannel])+
+resource++kukit... (line 5306)
notifyServer_done(XMLHttpRequest channel=[xpconnect wrapped
nsIChannel])++resource++kukit... (line 5217)
notifyServer_done()++resource++kukit... (line 5172)
[Break on this error] initializeMenus();
i'd still like to see this fixed before giving my thumbs up... (and
i'd really love to see 3.1 to ship with jquery... if there's anything
else i can do to help get this baby on the road, let me know!)
cheers,
tom
The only thing I could reproduce was the searchterm highlight thing
which I will look into.
Regards,
Florian Schulze
___
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 213 ready for review
On Jan 19, 2008, at 6:48 PM, Florian Schulze wrote: Hi! The buildout is at https://svn.plone.org/svn/plone/review/plip213-syndication-preps Notes are in the buildout. I guess this is the smallest PLIP of all :) yay, a nice small plip. it certainly works nicely during my clicktests. however, i have one problem, which is more svn-kungfoo related than to this plip. given the branch you've cut of CMFPlone https://dev.plone.org/plone/browser/CMFPlone/branches/plip213-syndication-preps how can i single out the changeset that you have done? i'd like to review the diffs that you made, i.e what seperates this branch from the revision that you cut it from. i must admit that i'm a bit overwhelmed here with that large listing. any pointers? other than that +1 from me on the plip. Regards, Florian Schulze ___ 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 213 ready for review
On 15.02.2008, at 11:34, Wichert Akkerman wrote: Previously Tom Lazar wrote: however, i have one problem, which is more svn-kungfoo related than to this plip. given the branch you've cut of CMFPlone https://dev.plone.org/plone/browser/CMFPlone/branches/plip213-syndication-preps how can i single out the changeset that you have done? i'd like to review the diffs that you made, i.e what seperates this branch from the revision that you cut it from. trac makes this trivial. If you go to http://dev.plone.org/plone/log/CMFPlone/branches/plip213-syndication-preps you will immediately see the only change: http://dev.plone.org/plone/changeset/18960 ah, perfect, thanks! i must have been blind. all i would have had to do is to click on the 'revision log' link. i'll try to remember that ;-) 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
Re: [Framework-Team] Re: Re: PLIP 212 ready for review
i'm happy to report that all remaining issues have been fixed by florian today. the reason that my findings were not immediately reproducible, turned out to be because they were triggered by KSS interactions, i.e. only if you previously had, for instance, performed a copy operation andthen a workflow step. once fschulze found that out he claims to have fixed several other issues of the same nature. i've assigned the ticket to witsch, for lack of knowing anything better. given that raphael has also looked at the plip i'd like to suggest to 'officially' include 212 for 3.1: how are we going to go about this? will we collect explicit votes from andi, martijn and danny? On 15.02.2008, at 13:41, Raphael Ritz wrote: Wichert Akkerman wrote: Previously Tom Lazar wrote: On Feb 14, 2008, at 1:57 PM, Florian Schulze wrote: I can't reproduce any of these issues. I tried my exisiting buildout and I made a fresh co of the buildout and ran buildout with the option to get the newest version of everything. well, given the fact that i indeed *can* reproduce these, chances are, others will, too. That's worrying. I would like to seem some succes/failure stories from others - FWIW: I just did a fresh buildout for 212 and tested a few things in firefox (inline editing, calendar pagination, display changes, workflow transitions, folder reordering, and running the tests from test_ecmascripts ). The only issue I've encountered is this one: opera_is_broken is not defined KupuSelectionTestCase()test_kupuhelpers (line 265) registerTestCase(KupuSelectionTestCase(), kupu)unittestUtilities... (line 9) opera_is_broken(this, 'testParentElementImg'); which Tom reported already. Raphael at the moment this feels like a big risk to me. Tom, can you write a short step-by-step guide for reproducing the problems you are seeing? Wichert. ___ 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 213 ready for review
after looking at the diffs -- :-) -- i'd hereby like to cast my approval of this plip, as well. On 19.01.2008, at 18:48, Florian Schulze wrote: Hi! The buildout is at https://svn.plone.org/svn/plone/review/plip213-syndication-preps Notes are in the buildout. I guess this is the smallest PLIP of all :) Regards, Florian Schulze ___ 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: Re: PLIP 212 ready for review
On 15.02.2008, at 11:56, Wichert Akkerman wrote: Previously Tom Lazar wrote: On Feb 14, 2008, at 1:57 PM, Florian Schulze wrote: I can't reproduce any of these issues. I tried my exisiting buildout and I made a fresh co of the buildout and ran buildout with the option to get the newest version of everything. well, given the fact that i indeed *can* reproduce these, chances are, others will, too. That's worrying. I would like to seem some succes/failure stories from others - at the moment this feels like a big risk to me. Tom, can you write a short step-by-step guide for reproducing the problems you are seeing? for the record: florian has been able to reproduce the issues, fixed them and i was able to confirm it. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Updated PLIP review deadline
On Feb 14, 2008, at 7:19 AM, Andreas Zeidler wrote: On Feb 7, 2008, at 1:01 AM, Martin Aspeli wrote: Once you post your reviews (here?) what happens? How does the team arrive at a final yes/no vote? How long does that take? hmm, i can't decide on these, of course, but i'd still like to try and get at least two reviews per PLIP. in case the reviews don't reveal major issues or otherwise warrant further discussion, i think that should do. every member of the team should read all of the submitted review notes and formally vote on the inclusion of the PLIP in question, though. with the deadline on the 16th and a sunday following that i reckon it should be easy enough for everyone to cast their votes by monday. in case not, could you please tell us asap? otherwise we should have a complete set of votes by monday night, at which point i'll post the verdict or rather the recommendations of the framework team. that should leave enough time for merging and last-minute polishing before the alpha freeze, which will presumably be on february 22nd now (assuming we're gonna shift the whole schedule by two weeks). does that sound alright with everyone? +1 from me For 3.0, each reviewer posted a thread here with the necessary comments, including good points, bad points and recommendations. i guess that's what the trac tickets were created for — the reviewers are supposed to update those with links to their notes, and i've cc'ed the authors when creating them. hmm, i guess that's assuming everyone had put their email address into their trac settings, but i'll make sure to cc everyone again when sending out the results on monday. We then reported back to the author (usually by just CC'ing them on the framework team list threads) and they were told either that it was rejected, or to make the necessary changes (if any) and prepare for merge. Wichert took the final decision on whether to merge or not. that makes sense, of course, and imho we should keep it like that. As a learning point, we (I) should have written down our process properly and handed it over better. i suppose that would have helped a bit here and there, but most of the problems we were seeing were due to lack of time anyway. I apologise for not doing this, relying on doing it verbally and letting you guys (especially Andreas) come up with your own take without too much guidance. no biggie — the important bit was to identify this during the summit, which will hopefully make sure things work better next time. cheers, andi ps: sorry for answering so late, btw. -- 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] Re: Updated PLIP review deadline
On Feb 14, 2008, at 1:22 PM, Martin Aspeli wrote: otherwise we should have a complete set of votes by monday night, at which point i'll post the verdict or rather the recommendations of the framework team. that should leave enough time for merging and last-minute polishing before the alpha freeze, which will presumably be on february 22nd now (assuming we're gonna shift the whole schedule by two weeks). does that sound alright with everyone? +1 from me That doesn't make sense, does it? my +1 was merely referring to shifting the schedule by two weeks, i wasn't aware of any inconsistencies in the first schedule. i don't think it makes any sense to condense the schedule to 'make up for time', especially not if it means that the plip authors are the ones to suffer from it. hth, tom If you give final votes/recommendations on Monday the 18th of February, and then you want to merge and freeze by Friday the 22nd, that leaves ... four days for people to react to your recommendations? That's insane! You need to at least give a weekend in-between. I thought that there were at least two weeks beteween final votes/recommended changes and final merges. Just deciding whether people have actually implemented the recommended changes and making the final decision to merge will take a few days. I don't think you can realistically freeze the alpha before March 3rd if you want all the packages in for the freeze. 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: PLIP 212 ready for review
hello florian, hello martijn,
i've completed my review and committed the notes in the svn bundle.
i repeated the manual tests with windows IE 6.0, but not with 7.0 as i
didn't have the time to install a new windows VM to install IE 7
without overwriting my existing 6.0 but since everything looked just
like in FF/Safari (i.e. the same stuff worked and the same stuff
didn't) i don't expect any big surprises there.
i also looked at some of the .js diffs and really liked what i
saw ;-), http://dev.plone.org/plone/changeset/18810 is a nice example
for that (livesearch.js)
i can't recommend this plip for inclusion in 3.1 in its current state,
however, alle the errors seem minor and easily fixable.
below i would also like to respond to florian's email in the same post
here:
On 12.02.2008, at 23:41, Florian Schulze wrote:
instead i got the following error in jquery.js (via firebug)
a is not a function
[Break on this error] eval(function(p,a,c,k,e,r){e=function(c)
{return(ca?'':e(parseInt(c/a)))+((c=c%a...
Note: this error remained, even after replacing the shipping jquery
version 1.2.2 with the meanwhile current version 1.2.3
This looks like a syntax error in that file. I will look into it.
well, since it's the jquery.js file itself, i kind of doubt it (which
also prompted me to try out the 1.2.3 version) but hey! you're the
expert ;-)
This is either another syntax error, or some issue with the KSS
interaction.
you tell me ;-)
= running unit tests =
running all tests (./bin/instance/test -v -v -s plone) produced the
following result:
Tests with failures:
test_published_news_items
(plone.app.portlets.tests.test_events_portlet.TestRenderer)
test_published_news_items
(plone.app.portlets.tests.test_news_portlet.TestRenderer)
/opt/zope/buildout/eggs/plone.app.workflow-1.0.1.1-py2.4.egg/
plone/app/workflow/tests/onestateworkflow.txt
Total: 1079 tests, 3 failures, 0 errors
I didn't look into this at all, because we didn't change anything
besides JS code and some registrations in JS registry.
true, especially after i now looked into those diffs for myself, i
wouldn't label these failures 'showstoppers' for this plip.
I will look into upgrading the buildout to the latest Plone version
if it isn't already.
that would be cool
best regards,
tom
= code review =
to be done (check migration, look into the js code changes)
Regards,
Florian Schulze
___
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 212 ready for review
hi florian, hello fellow framework team members,
i started reviewing plip 212 on the plane back to berlin and got most
covered. i committed my initial review and post a copy of it here, for
your convenience. i still need to repeat the click tests i've done
with IE 6 and IE 7, as i haven't got Parallels installed on my macbook
(yet). also, i intend to look at the js code changes and migration
stuff, but judging from my previous experiences with florian's code i
don't expect any snags there. however, i did run into a few problems
with this buildout and currently don't think it's ready for merging,
see my notes below. i will continue the review tomorrow evening, along
with my other outstanding reviews.
cheers,
tom
--snip--
Note, all tests have been conducted with jquery 1.2.2 which is part of
the bundle, as well as with version 1.2.3 which is currently the
latest revision of jquery.
= manual click tests
performed with fresh checkout, new instance with Plone Default skin.
Using Firefox 2.0.0.12 and Safari Version 3.0.4 (5523.15), Win IE 6 +
7 tbd. Features and areas covered:
* livesearch, portal calendar pagination, external links, inline
editing, folder_contents reordering:
no problems encountered, everything worked as expected.
* highlighting of search results
This didn't work on any browser. Calling a url such as http://localhost:8080/jquery/front-page?searchterm=comfortable
would not actually highlight the word (eventhough it exists in the
default front page)
instead i got the following error in jquery.js (via firebug)
a is not a function
[Break on this error] eval(function(p,a,c,k,e,r){e=function(c)
{return(ca?'':e(parseInt(c/a)))+((c=c%a...
Note: this error remained, even after replacing the shipping jquery
version 1.2.2 with the meanwhile current version 1.2.3
Additional errors:
the display menu wasn't working as expected, i.e. the click action on
the display menu was not caught but instead resulted in a page load of
the `select_default_view`, however, this only occurred with jquery
1.2.3, 1.2.2 worked fine.
workflow actions however didn't work in neither 1.2.2 nor 1.2.3, i.e.
publishing resulted in a page load instead of just a viewlet refresh.
= running unit tests =
running all tests (./bin/instance/test -v -v -s plone) produced the
following result:
Tests with failures:
test_published_news_items
(plone.app.portlets.tests.test_events_portlet.TestRenderer)
test_published_news_items
(plone.app.portlets.tests.test_news_portlet.TestRenderer)
/opt/zope/buildout/eggs/plone.app.workflow-1.0.1.1-py2.4.egg/plone/
app/workflow/tests/onestateworkflow.txt
Total: 1079 tests, 3 failures, 0 errors
= code review =
to be done (check migration, look into the js code changes)
--snap--
On Jan 19, 2008, at 8:30 PM, Florian Schulze wrote:
Hi!
The buildout is at https://svn.plone.org/svn/plone/review/plip212-jquery
Notes are in the buildout. This PLIP needs to most QA I guess.
Especially the folder_contents stuff should be tested, as I found
some typos in there and I don't know the full functionality set of
it to test it. It's part of the kss plugins.
Regards,
Florian Schulze
___
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
Fwd: [Framework-Team] Two more reviews primed
repost of rejected mail to list since i used the wrong sender-address. Begin forwarded message: From: [EMAIL PROTECTED] Date: February 9, 2008 10:42:09 AM GMT+01:00 To: [EMAIL PROTECTED] Subject: Re: [Framework-Team] Two more reviews primed You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at [EMAIL PROTECTED] From: Tom Lazar [EMAIL PROTECTED] Date: February 9, 2008 10:41:34 AM GMT+01:00 To: Andreas Zeidler [EMAIL PROTECTED] Cc: Martijn Pieters [EMAIL PROTECTED], Framework Team framework-team@lists.plone.org Subject: Re: [Framework-Team] Two more reviews primed i can do the jquery one probably already on monday, if all goes well here, tuesday is busy getting stuff ready here and travelling back but i could finish all four by wednesday for sure. hth, tom On Feb 8, 2008, at 11:54 PM, Andreas Zeidler wrote: On Feb 8, 2008, at 9:24 AM, Martijn Pieters wrote: I will take a look at PLIPs 205 and 218 next, this weekend hopefully. just a really quick note, since we're about to continue here... i've just compiled a review status (which i'll post later), but essentially there are four PLIPs left with no reviews at all at the moment. those are: #201: Improve the UberSelectionWidget UI #209: Add buildout to Unified Installer #212: Use jQuery Javascript Library #215: Include new KSS versions so, martijn, could you please prefer one or two of those over #205/ #218, and tom, which of those will you be able to review and when? let's make sure we can at least one review in for each submitted PLIP as soon as possible! 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] February 16 Deadline?
thanks for the post george, i will definitely be able to meet the feb 16th deadline and hereby volunteer to additionally pick up any 'leftovers' if neccessary! cheers, tom On Feb 9, 2008, at 9:30 PM, George Lee wrote: Hi, When Andi suggested the February 16 deadline, it seemed to be based on some scattered conversations on-list, off-list, and on IRC. Nobody replied on-list saying that this deadline would definitely work for them, although that has since been set as the official new deadline. There has also been a general lack of reply to Andi's recent e-mail about the remaining four unreviewed PLIPs. For the sake of transparency to the rest of the developers not on the framework team, can the framework team members please reply on-list to say whether they can really meet this deadline? Martijn has been doing reviews since the new deadline announcement, but personally I feel left in the dark whether the whole team is really committed to the February 16 deadline. Peace, George ___ 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 deadline coming up
just for the record: i'm absolutely fine with plip 224. i think it's an important (and well written) proposal. also, it really fits the profile IMHO. if i didn't have so many other plips already, i'd take a look at this one, right now... cheers, tom On 03.02.2008, at 02:35, Andreas Zeidler wrote: hi team mates, On Jan 31, 2008, at 9:28 PM, Andreas Zeidler wrote: * as for me, i'm planning to be done with my share by this saturday fyi, it's two hours and a little bit past the original deadline now and so far i've finished reviewing bundles for the following PLIPs: * PLIP 213: Prepare for better Syndication (see ticket #7748) * PLIP 205: Flexibility Associating Portlet Types and Portlet Managers (see ticket #7740) * PLIP 218: Increase Restrictions, and Ability to Change, Addable Portlet Types by Interface (see ticket #7752) * PLIP 207: Allow Custom Portlet Managers (see ticket #7741) * PLIP 208: Adapter-Based Local Role Lookup (see ticket #7743) * PLIP 217: Use Adaptation for Workflow Assignment (see ticket #7751) * PLIP 220: Improve browser layer support (see ticket #7754) i'm currently planning to do one more review, which will be the late submitted PLIP 224. this is presuming it'll be accepted by the team, of course. since it's not yet i'll wait with the review until it has, but probably won't have time to do so before the flight to the summit, i.e. next thursday. also, PLIP 208 still requires a full review of `borg.localrole` (instead of only the parts changed by the PLIP), which i'll try to make up for on the plane as well... 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 Tom Lazar http://tomster.org ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: pyflakes? (was: Re: [Framework-Team] Translation effort for Plone 3.1)
On 01.02.2008, at 12:07, Andreas Zeidler wrote: On Feb 1, 2008, at 12:04 PM, Martijn Pieters wrote: On Feb 1, 2008 11:51 AM, Andreas Zeidler [EMAIL PROTECTED] wrote: talking about weeding out stuff bring another thing to mind. not exactly related to translations, but i'll throw it in here anyway: tools like pylint[1] and pyflakes[2] have really grown on me ever since i started using them. imho they not only help with keeping code clean, but also with quickly catching typos and errors, effectively saving you a lot of time. Careful with weeding imports. I recently had to fix a migration issue for a customer, where a persistent tool had been moved into another module with an import at the old location. Someone else then ran pyflakes and removed said import, breaking the migration. yes, i'm very much aware of these problems having used pyflakes myself for quite some time now. that's one of the reasons i'm bringing this up here (instead of starting to weed away on trunk :)). given the aforementioned possibility of 3rd party breakage i think it's plain that 'pyflakes sanity' is a no-go for 3.1 but perhaps for 4.0? since that will necessitate 3rd party rewrites/adaptions anyway, might as well throw in pyflakes sanity, as well. i envision a pyflakes wrapper that weeds out some of the stuff that pyflakes ist just not smart enough about (i.e. the warnings it generates for undefined name '__path__' etc.) and that a error and warning free run of that wrapper would be mandatory just as zero failures are mandatory already. ah, well, one can dream... ;-) cheers, tom p.s. i made statusmessages 'pyflakes-sane' when you introduced pyflakes to me at the labelfinder and right after hanno visited us there and helped me fix a bug in it ;-) 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
Re: [Framework-Team] Re: PLIPs 208 and 217 Ready for Review
updates and fixes would only go into the new package. of course, we'd leave the old packages around. and, of course, maintaining two branches just for naming reasons is out of the question. we can add a note in README.txt or somesuch and make an announcement at the product's PSC presence. that should do the trick IMHO. i'm all for bringing stuff like this into the plone namespace. just my $0.02, tom On 01.02.2008, at 12:12, Andreas Zeidler wrote: On Feb 1, 2008, at 9:51 AM, Alexander Limi wrote: Just a general question here, while I remember it: When things like this happen, shouldn't packages be renamed to plone.localrole instead of borg.localrole? hmm, i'm not sure. it would surely lessen confusion, but otoh a lot of packages (and buildouts for that matter) depend on that package, so changing the name would cause quite a bit of migration headaches. of course it'd be possible to leave the old version around for a while, but what about updates and fixes? and maintaining another branch just because of this seems a bit too much, imho. 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
Re: [Framework-Team] Re: PLIPs 208 and 217 Ready for Review
i'd like to make a case for 'building the plone brand' not only for the integrator/user audience (as we already are doing) but also for the develeoper audience. let's not be too shy or modest here. borg is as 'plonish' in regard to its cleanliness, documentation, extensibility etc. as it gets (naturally, with martin being the author). i think it could make sense to convey this by using the plone namespace for it and i'm sure there are other packages, too. coming up with eccentric namespaces in the beginning of a new product's lifecycle is a good idea (we'd have to have three plone.commenting products right now, otherwise, none of which is finished...) but eventually i'd think it's a good idea to 'bless' a package and bring it into the plone namespace. otherwise we'll just 'dilute our brand' for the developer audience. of course, i'm still all for integrating 3rd party tools (and keeping their name, of course!) but to 'simulate diversity' by letting our own packages keep their initial, non-plone name when integrating them into plone core doesn't strike me as particularly desirable (or straightforward, for that matter), either. just my $0,02 and i'd love to know what you guys think about it... cheers, tom On Feb 1, 2008, at 1:41 PM, Andreas Zeidler wrote: On Feb 1, 2008, at 12:31 PM, Martin Aspeli wrote: -1 to renaming everthing plone.*. When things begin outside Plone (which we should encourage), then we can't necessarily insist that they are called plone.* (in fact, we'd probably discourage it if it wasn't intended to be eventually destined for the core). i completely agree. furthermore, i think using non plone.* packages in plone emphasizes one of the points made in the whole wsgi/repoze approach and the plone. (as opposed to plone.app.) namespace, which is that re-usability is a good thing and we'd like other people outside the plone/zope universe to start looking and potentially using our stuff as well. in that sense i think we should actually make a statement by integrating packages from the outside world. and yes, that's not particularly true in this case, but at least it looks this way... ;) 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
Re: [Framework-Team] Re: PLIPs 208 and 217 Ready for Review
i think the penalty aspect martin mentions (apart from the effort involved in renaming, which could be spent easily elsewhere) pretty much does it for me. i rest my case. cheers, tom (who may be vain, but not passionately so ;-) On Feb 1, 2008, at 2:24 PM, Martin Aspeli wrote: Hi Tom, On 01/02/2008, Tom Lazar [EMAIL PROTECTED] wrote: i'd like to make a case for 'building the plone brand' not only for the integrator/user audience (as we already are doing) but also for the develeoper audience. let's not be too shy or modest here. borg is as 'plonish' in regard to its cleanliness, documentation, extensibility etc. as it gets (naturally, with martin being the author). i think it could make sense to convey this by using the plone namespace for it and i'm sure there are other packages, too. Renaming things means moving module paths. That breaks persistent objects and third party imports. It effectively penalises those who used this package (and and thus helped make it stable enough for the core) already and forks the original code base in case people already depend on it and thus need to continue to develop it. We are doing plenty of designed-for-the-core packages in the plone.* namespace, and honestly I don't think we need to be so vain that we can't use packages not in our namespace. I think it's a very nice, positive statement that we don't, in fact. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] review deadline coming up
hi guys, i'm afraid i'm pretty much swamped with work- and family obligations until february 12th when i'll return from the GSM World trade fair in barcelona. until then i'm daily at a client where we are prepping a (plone based!) demo app for the tradeshow and/or at home looking after the kids while my wife is at her new job. i'll try to squeeze in some review time if i can, but truth be told, most evenings i'm just too shattered after a full day of coding and conferencing to fire up buildout. i am however, for instance, extremely interested in florian's jquery plip and i will definitely have a look at that *before* the 12th just out of pure curiosity ;-) my apologies for not being able to keep the deadline, cheers, tom On 31.01.2008, at 12:13, Andreas Zeidler wrote: On Jan 31, 2008, at 11:47 AM, Martijn Pieters wrote: On 30. jan.. 2008, at 01.44, Andreas Zeidler wrote: * 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? No preferences, I can do reviews next week. Right now the aftermath of the move is still swamping me; lack of network connectivity is but a tiny part of the problem, it's the mountain of tasks to get the house in order that I have to worry about right now.. ;-) tom, danny, what about you? could you give us an update of your status and estimate when you're gonna be able to do the reviews, please? the original deadline is the day after tomorrow and we haven't had any word from you about which plips you'd like to review and when... 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 Tom Lazar http://tomster.org ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP #215: Include new KSS versions
a big 'thank you' from me, too. i think the changes you mentioned are well worth including in 3.1 and i will definitely review this plip, too (also it fits quite nicely with florian's jquery plip) again, i will try to fit this in before the 12th (but no promises...) cheers, tom On 30.01.2008, at 21:02, Raphael Ritz wrote: Balazs Ree wrote: Finally... (drum roll): https://svn.plone.org/svn/plone/review/plip215-new-kss-version Thanks Balazs, this is great news. Irrespective of the delay I'll definitively take a look and comment on it. 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] review deadline coming up
i, too must apologize for my lack of reviewing so far. i'm busy in a project and my wife has started working again this month. add two kids and a pesky tax deadline to the equation and geek time approaches zero... andi and i are going to meet this week and will do some review work together (and come up with some sort of overview) we'll post back when we've met. cheers, tom On Jan 28, 2008, at 10:13 AM, Wichert Akkerman wrote: The review deadline for all PLIPs is this Saturday, a mere 5 days from now. Does anyone have an overview of the current review status? 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
Re: [Framework-Team] PLIP #215: Include new KSS versions
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 ;-) cheers, tom p.s. have fun in austria, wish i could be there... On 20.01.2008, at 02:04, Balazs Ree wrote: Dear Framework Team, we finished the preparation of the new kss.core version we propose for Plone 3.1. However, we needed some time to discuss the implemented code, and in the case that we had doubt or argument about a particular feature, we decided to pull them out from the release and retarget them for the next release, which makes it possible to discuss them properly. Since we are after the first day of the sprint, I succeeded to build and test the version that contains our all merged code, but still I have to pull back the above mentioned functionality. Which means, I will only be able to submit the review buildout by tomorrow (20th) lunchtime. I hope that this delay will be accepted. I also needed to cancel the other topic I promised, the refactoring of plone.app.kss and archetypes.kss. These are also retargeted for the next release. Altogether, we had a lot of discussion that will lead to better, simpler kss and the current version will be a conservative release to assure the stability of Plone. Thanks for your understanding, -- Balazs Ree ___ 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] Organizing the review
andi, sorry about the silence, i've fallen a bit ill (that noro virus that's going round here in berlin, watch out...) i think the idea with trac is excellent and have, in fact, been harbouring similar ideas in that regard but kept quiet since i knew that i don't have the resources right now to do something about. it would be great, if you could set up a trac instance to get us up and running. thanks, tom On Jan 18, 2008, at 3:53 PM, Andreas Zeidler wrote: On Jan 16, 2008, at 12:20 PM, Andreas Zeidler wrote: so, how about (ab)using trac tickets to assign plips to team members and collect review notes etc? that way people could be cc'ed to make sure the author(s) and relevant team members get the news. plus using an additional query it would be easy to see what's already done/assigned/pending etc... what do you think? hmm, not too much it would seem... :) does anyone have a better suggestion on how to coordinate the review? if not (and if nobody objects) i'll go ahead an create those review tickets some time during the weekend... 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
Re: [Framework-Team] Re: Official submission: PLIP 184, 200, 203 and 204
wiggy, you are right. i wasn't wearing my 'user perspective glasses' ;-) cheers, tom On Jan 16, 2008, at 9:05 AM, 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 :) 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
Re: [Framework-Team] Re: Official submission: PLIP 184, 200, 203 and 204
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. just my $0.02, hope this doesn't sound too formal, but i just happen to disagree with wiggy's assesment that 'something that worked in 3.0 is about to break in 3.1'. tom On 15.01.2008, at 23:41, Martin Aspeli wrote: Wichert Akkerman wrote: Previously Raphael Ritz wrote: 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. It is not borderline: we can't break things in 3.1 that work in Plone 3.0. This isn't breaking anything that worked in 3.0 - it just means that a new 3.1 feature (formlib wysiwyg editor) won't work with a particular third-party product installed and enabled. Of course, it should be fixed, but it may be that the fix needs to go into FCKeditor if it's doing something non-kosher; alternatively, we may need to build a bit more safety into the 3.1 feature to deal with a special case for FCKeditor. I don't think I can do anything to fix before the Planning Summit (after the submission deadline), but I also don't see why that should matter. If someone else who actually uses FCKeditor has some time to look at it, I suspect it'll be a simple fix. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ 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
On 15.01.2008, at 22:43, Hanno Schlichting wrote: Raphael Ritz wrote: Wichert Akkerman wrote: 2. Not sure it's the best possible UI to completely hide a product if a dependency is missing. [...] I'ld like some input from Hanno on that. What I did was update the isInstallable method in the quickinstaller tool, which seemed the logical place to put it and makes sure all the standard APIs and code paths do the right thing. QI has never had a user interface or API that communicates why a product is not installable and I'm not sure what the best way to add this is. Well, for testing purposes I just deliberately introduced a typo in the PloneLanguageTool (of Plone 2.5.4 to demonstrate that this is not new; removed a colon in line 60) and in 'prefs_install_products_form' I get: Broken products Some products were found to have errors when compiling the install file. * PloneLanguageTool Error Type exceptions.SyntaxError Error Value invalid syntax (Install.py, line 60) That's what I meant. Along the same line we could just list products with broken dependencies here as well as they are checked anyway. This seems like a good approach for me right now. I do have some plans to do a major update to the installation logic for Plone 3.2 so a better UI can probably wait until then. Right now the dependency support is the most frequently asked for feature, so lets get that out to people :) amen, brother ;-) cheers, tom 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] Re: PLIP #187 for Plone 3.1
for the record, i totally second andi's approach re: the deadline issue. it's a tricky dance, for sure and we must never forget that we're dealing with voluntarily submitted offers of (often) hard work which shouldn't be cast aside lightly, but then again, we do need a timetable in order to get out releases in a timely fashion and there definitely will be a 3.2 coming along not too far down the road. just my $0.02, tom p.s. and yes, maybe it *is* a german thing, andi ;-) On Dec 22, 2007, at 2:20 PM, Andreas Zeidler wrote: hi martin, On Dec 22, 2007, at 1:27 AM, Martin Aspeli wrote: Andreas Zeidler wrote: i don't mind about a few hours or timezone differences, but imho we should consider plips which have been submitted more than a day late. that should have read shouldn't, of course — sorry for any confusion. Given that this is just the proposal deadline, what's the point in being so strict? i just don't think it makes much sense to first give a deadline and than right away let it slip again, especially with a newly introduced step in the process. imho we should try to stick with what we've decided and not sort of give out the message that it's okay to be late. you're right of course in saying this is only the proposal deadline, which is not an important one, but then again people would like to know if their plips have been accepted asap, and i guess the late submissions are already causing a delay, since half of the missing votes are for them. and that's not counting the proposed additions in non-plip form. otoh i don't think we should or need to be too strict either, which is why i've included #187 and #221 in the list of pending proposals and also reviewed and voted for them. i've also made the lateness a low priority aspect when voting, since we weren't very specific about handling this beforehand. Since we're not merging anything at this point, it's hardly going to delay the release (presuming the later deadlines for review bundles etc are met). that's right, but all of the above is just my personal opinion and does not in any way represent the framework team. it's totally fine with me if my team-mates think otherwise and outnumber my (non- negative) votes here... :) however, i think we should indeed be strict with the review bundle deadline and also with future plip submission deadlines. maybe it's just a german thing or something, but imho it shouldn't be to hard and/or time-consuming to write or at least draft a plip and send out an email to the framework team within almost three weeks after the announcement of the timeline, no? 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.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 mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] A question about bundles and PLIP 203
On 21.12.2007, at 10:21, Wichert Akkerman wrote: Martin Aspeli wrote: Hi guys, I have two, somewhat related questions: - For pretty much all of my PLIPs, I'll be changing one package only. I suspect many Plone 3.1 PLIPs will be the same. I can obviously create a buildout (copying ploneout/branches/3.0 and changing the svn:externals in src/ to point to my branch), but this will quickly lead to a ton of buildouts, the majority of which will be very similar. How do you feel about a lite review bundle that basically is just an instruction like Use ploneout 3.0 branch and svn switch src/ plone.app.portlets to the following URL? Perhaps it's a good alternative for you guys in cases where there's only one package that's changed? What I did so far is use a plone.recipe.plone based buildout for my PLIPs. That way you get a very light-weight easy to install and download buildout that only includes the parts that are specific for my PLIP. I think that makes it easier to review them as well. yes, please. or look at it this way, martin: the extra effort of creating a buildout/recipe will pay off in faster review time (at least speaking for myself...) just my $0.02, 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
Re: [Framework-Team] PLIP 220: Improve browser layer support
On 14.12.2007, at 21:18, Wichert Akkerman wrote: I want to propose PLIP 220: http://plone.org/products/plone/roadmap/ 220 +1 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
Re: [Framework-Team] Two more PLIPs
now that i've understood what it's about: +1 from me, too ;-) thanks raphael! cheers, tom On 13.12.2007, at 08:41, Raphael Ritz wrote: Tom Lazar wrote: On 11.12.2007, at 13:35, Laurence Rowe wrote: I'd like to see the following for 3.1: #210: Improve UI support for objects on multiple workflows DCWorkflow allows for a chain of workflows to be specified for a type. please explain. does chaining mean, that an object/type can have multiple workflows associated sequentially? or does each given state have the sum of all of the workflows transitions available? More the latter than the former. Objects can be subject to several workflows at once. This implies multiple state variables of course. Indeed you get a sum of all possible transitions offered. I used to use this feature to provide locking functionality before Plone itself did it (but in a different way now). If you want to see an example in action check out my LockingWorkflow product in a Plone 2.5 site. And to drive home the point here: the CMF workflow tool and DCWorkflow have supported this from the onset. It is only Plone's UI that's kind of hiding this from you. and BTW: +1 from me on the issue or does one simply chose one workflow for different instances of a content type? i.e. the frontpage has a restrictive workflow and the faq page has a more permissive one.? This mostly works with Plone, but there are a few (mostly UI) warts to be fixed. http://plone.org/products/plone/roadmap/210 #211: Enable dashboard to be locked down Portlets may be registered to the dashboard for groups, this makes the dashboard useful even when users should not be able to modify their own dashboard. http://plone.org/products/plone/roadmap/211 definitely +1 on Protect the dashboard with a 'Portlets: View own portlets' permission but also to the switch to registering portlets to AuthenticatedUsers group +1 here as well Raphael 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] collecting votes / assigning plips to 3.1 in PSC
On 13.12.2007, at 13:33, Andreas Zeidler wrote: so, all in all i'm -1 for adding them right away. sure, no problem. after the deadline is just fine, too. (and much simpler in this case) ___ 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
On 12.12.2007, at 18:45, Raphael Ritz wrote: 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. well, depending on the implementation of the override, one might be enough. the way i understand alec, the CMFPlacefulWorkflow would override the default with a context aware (i.e. placeful) version. but i like the sound of the idea a lot. But I'm confident Alec will get it right ;-) if not he... ;-) 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Two more PLIPs
On 11.12.2007, at 13:35, Laurence Rowe wrote: I'd like to see the following for 3.1: #210: Improve UI support for objects on multiple workflows DCWorkflow allows for a chain of workflows to be specified for a type. please explain. does chaining mean, that an object/type can have multiple workflows associated sequentially? or does each given state have the sum of all of the workflows transitions available? or does one simply chose one workflow for different instances of a content type? i.e. the frontpage has a restrictive workflow and the faq page has a more permissive one.? This mostly works with Plone, but there are a few (mostly UI) warts to be fixed. http://plone.org/products/plone/roadmap/210 #211: Enable dashboard to be locked down Portlets may be registered to the dashboard for groups, this makes the dashboard useful even when users should not be able to modify their own dashboard. http://plone.org/products/plone/roadmap/211 definitely +1 on Protect the dashboard with a 'Portlets: View own portlets' permission but also to the switch to registering portlets to AuthenticatedUsers group 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] Re: PLIPs for 3.1
On Dec 9, 2007, at 1:45 PM, Wichert Akkerman wrote: Previously Martin Aspeli wrote: ... there's another kind of portlet which we can provide (ship with or not, up to you guys) - a referenced content portlet. Here, you search (using an UberSelectionWidget) for a Page that's then rendered as content. We can provide multiple renderers depending on what was selected (plone.portlets has some design provisions for this exact use case), so that there's a portlet-specific view for a Document that's different to one for an Event, say. The collection portlet is just that. Once you go down that road I would prefer a more general approach where we introduce the concept of context-based rendering, or tile-based rendering as some people call it. Basically the idea is that you want to render a particular object in different kinds of places/sizes: portlets, collage slots, main page body, reference, etc. This is something that I requested more and more often and it makes sense to try and come up with a proper infrastructure for handling it. that sounds interesting and also would cover some use cases that clients of mine have floating around. i like the term 'tile based rendering'. is there some (semi-formal) concept behind that term? with me it conjures up the idea of being a whole lot more flexible in how site managers (i.e. not developers!) can structure and re-use content. something like 'big' websites such as ny times, spiegel.de etc. use, where e.g. an article can have two, three different kind of teasers that are rendered in different sizes in different contexts etc. 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.) finally, i think we should tread carefully here, though, as there have already been numerous and vociferous complaints regarding how complicated the porlet infrastructure has become. any design should not increase the complexity for the existing use cases. just my $0.02, 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
Re: [Framework-Team] PLIPs for 3.1
hi everybody, here's my feedback on the plips submitted by martin. On Dec 2, 2007, at 6:19 PM, Martin Aspeli wrote: 1. http://plone.org/products/plone/roadmap/184 - Ship additional portlets This is actually raised by Jon Stahl, but I've been involved in the implementation of the portlets he's talking about (collection, static text, document rendering). I'd like to tidy up the portlets a bit (especially if the formlib PLIPs below are accepted and implemented). After that, this should be as simple as deciding to ship with a few extra eggs. definitly +1 on the static content portlet with richtext editing. dito for the collection portlet. not sure whether it makes sense to ship an rss portlet, though. pulling in external content is a nice idea but including it in the default setup somehow doesn't feel right. few people will use it, i assume, and we shouldn't slip into feature bloat, just 'because we can'. i'm also not sure how to treat static portlets conceptually. i.e. as pages (that just 'happen to be displayed in a column') or as non- content. this raises further questions, i.e. how to treat their content when searching a site? their content should definitly be included in searches IMHO, but how treat them in result listings? since they might be conext sensitive they really don't have an absolute_url. OTOH using a central place to instantiate the static portlets which are then just referenced in the assignment instances (as suggested by jon in the plip) doesn't seem quite right, either (although it does solve the search and absolute link problem nicely). any suggestions here from my fellow board members? the following three plips (200, 201 and 202) are based on the fschulze- optilude-usw branch of plone.app.form, which i've tried to check out using a current version of ZopeSkel (1.3) and plone.recipe (3.0.4) but failed with a version conflict, since the recipe already includes plone.app.form. i tried various buildout.cfg changes without success and then briefly considered but ultimately refrained from using ploneout, since that (presumably) is based on plone trunk a.k.a. plone 4.0, so the following comments are based on reading the plips and looking at the abovementioned branch's code, only. (perhaps somebody can offer a quick way of getting ones hands on an instance of the branch or i'll just wait for the review bundle.) 2. http://plone.org/products/plone/roadmap/200 - Kupu formlib widget We need a Kupu/WYSIWYG widget for formlib-base forms. I'd like to thise this in portlets as well as formlib-based content types. The implementation here is largely complete. +1 on the idea, especially including portlets. it would be nice to be able to configure what features/buttons are included when rendering kupu as often it's really overkill and increases pageweight. http://plone.org/products/plone/roadmap/201 - Improved UberSelectionWidget This is about AJAX-enabling the UberSelectionWidget. Andreas and Florian and I have started this work already - it just needs a bit more JavaScript love. Again, I'd like to use this widget in a few more portlets, content rules and formlib-based types. +1 this, too, sounds very cool and desirable. i'm especially keen on the 'quicksilver like' functionality. i'm probably hoping for too much, though, when imagining myself typing 'fbr' to match 'foobar', since i assume that would require a completely new kind of index, no? 3. http://plone.org/products/plone/roadmap/202 - KSS inline editing and validation for formlib forms +1 on the design goal. i really missed this feature on a recent project ;) in the demo template, where is the kssattr namespace defined, which is used in i.e. kssattr:fieldname=title. is that something new from this plip or a general convention? it seems a bit redundant, since we also have tal:content=context/Title. then again, it is of course, nice to be able to 're-wire' fields straight in a template. but perhaps, in a grok/RoR spirit we could come up with some kind of default mechanism that maps the kss fieldname with the context. the rather clumsy class attribute is generated at runtime via KSS, i assume, so there's probably no need to make that a bit more 'human friendly'. 4. http://plone.org/products/plone/roadmap/203 - Manage portlet assignments with GenericSetup This is about making it easier to set up portlet assignments in GS profiles. I have a design for this, but no code yet - I plan to work on it over Christmas. +1 on the design. this is pretty much exactly what i would like to be able to do ;-) 5. http://plone.org/products/plone/roadmap/204 - Manage content rules using GenericSetup This is quite similar to 203. Again, no code, but I know how to do it and hope to get it done for January. can't really comment on whether the suggested syntax is entirely logical and complete as i'm not familiar with
Re: [Framework-Team] review bundle for PLIP 195 ready
On 03.12.2007, at 23:12, Wichert Akkerman wrote: Previously Wichert Akkerman wrote: I have prepared a review bundle for PLIP 195: https://svn.plone.org/svn/plone/review/plip195-dependencies There were a couple of bugs related to handling of export steps in GenericSetup. Those have been fixed now and I have updated the bundle to include them. 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. 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? 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. 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! 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
Re: [Framework-Team] Re: PLIPs for 3.1
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. cheers, tom On Dec 3, 2007, at 11:20 AM, Andreas Zeidler wrote: On Dec 2, 2007, at 6:19 PM, Martin Aspeli wrote: Hi team, hi martin, I'm submitting the following PLIPs for Plone 3.1. thanks for submitting these — unfortunately i won't have time to read them today, but i'll catch up and comment some time later this week. having that said, could we, i.e. the team, try to keep casting votes relatively soon after new submissions to avoid blocking things and/or creating a backlog for ourselves? in this particular case i'd suggest the end of the week if that's okay with everyone? 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] PLIP #195: Support product dependencies
On Nov 26, 2007, at 12:02 PM, Andreas Zeidler wrote: On Nov 26, 2007, at 11:03 AM, Wichert Akkerman wrote: sounds great to me, esp after having to manually install eight or so packages for every new test site in the correct order for far too long... :) so, i'm +1 for accepting the PLIP. Great! Perhaps it would be practical to select a spokesperson/ coordinator for the framework team who will deliver the final verdict? yes, it sure would. i've already picked up that suggestion (by martin) and sent a mail to the team members asking, but haven't got any responses yet... :) /me cheers for andi as spokesperson ;) regarding #195 i'm also +1. what i like about it, is that the actual 'heavy lifting' is done in the new versions of GS and CMFQuickInstaller and the plip 'only' addresses their integration. also, feature-wise it's a perfect candidate for 3.1 imho as it adds a much requested feature w/o breaking anything. rock on. my $0.02, tom 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] Move footer.pt and colophon.pt to viewlets?
On 07.06.2007, at 02:18, Martin Aspeli wrote: This is a bit late in the game, but I'd like to offer for consideration whether we should move footer.pt and colophon.pt to viewlets? Why? Because custom skins very often want to hide these. With the (incredibly cool) new viewlet manager from fschulze, we could make this very easy. As it stands, you still need to customise both of these (and/or main_template) to remove/change them. Thoughts? +1 also just FWIW (not being on the framework team etc.) but from my experiences with viewlets from the PIKtipi sprint i think these ought to be viewlets, as well (even if just for sake of consistency). Martin -- Acquisition is a jealous mistress ___ 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: plone.theme - one more package for Plone 3?
On 21.05.2007, at 23:57, Martin Aspeli wrote: whit wrote: I would say this point you are at wiggy's mercy. 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!) Me too :) He tends to like things with tests, though. ;) 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] plone products leaders (v2)
On Mar 17, 2007, at 8:35 AM, Thierry Benita wrote: What do you think of this idea ? Do you think that it is possible/affordable ? + 100 and thanks for the nice writeup, i think this initiative comes at a very good time, because on the one hand we definitely need to lighten the load of responsibility that currently is divided among the very few shoulders of our 'rock stars'. but on the other hand, plone's embracing of the z3 component architecture should actually make that kind of sharing of responsibility much easier (and more precise). take hanno's `statusmessages` product for instance, a super small product all in itself. just yesterday i found a bug in it and given the fact, that the entire functionality is just a few lines of (isoltaed) code i was (surprisingly) easily able to come up with a patch. however, as thierry described, i was too shy too directly commit it, so i sent the patch to hannosch for his review (still pending, the guy does need some sleep, after all! ;-). however, now that i'm fairly familiar with this product's inner workings i already would feel confident taking over maintainership of it, while hannosch still remains 'mentor' of it. so, perhaps, to ease the transition the current de facto maintainer of a package could offer 'mentorship' (i.e. provide support for the maintainer, as opposed to everybody). on a practical level, i guess we could just simply start with using this mailing list for the process of offering packages up for maintenance and applying for them and use the product's READMEs to keep track of who's taken over what (perhaps with some standardized text format for grep-convenience). just my EUR 0.02, tom ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
