Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
Great work so far, framework team! On 8/17/10 10:39 PM, Eric Steele wrote: * 30 PLIPs! * Cover those PLIPs which were dependencies of other PLIPs first. • 9473 (z3cform) • Ross: Better than Archetypes at form generation, better documentation than formlib, but still requires a lot of knowledge of the internals to work with. • (Small?) improvement over formlib, extensive (but not very approachable) documentation. • Approachability can be improved with layers on top: autoform, dexterity. • Heavy Plone adoption will likely lead toward better documentation. • plone.app.registry makes it largely transparent • Approved Fwiw, Martin has some partly-finished more approachable documentation at http://plone.org/products/dexterity/documentation/manual/schema-driven-forms/. He needs some help finishing it though, as he's busy updating his book. • 10877 (Plone/CMFPlone egg separation) • Concerns: • Subversion location change • Confusion of integrators looking for moved code • Win for application developers after a more stripped-down Plone, transparent to the remainder • What do we gain by doing this in a minor release? • Not particularly needed right away, but it's something that would be widely used if available. • Low risk • Precedent in Plone 3.2 • Eventually make Archetypes optional. • Should be an immediate change. Other plips will be branching Plone, it'll be a mess to merge. +1, Good call. (Too late for a few of us though...oh well, hopefully with svn mergeinfo it won't be too bad.) • 10787 (Site admin role) • Like the idea. Nervous about required updates, reindexing • Everyone who would be assigned this new role would have previously been a manager. Should be safe enough for a minor release. • Add site admin group? I've been meaning to add that as a task to the ticket. • Concern over ability of site admin to assign themselves manager rights • Remove sharing page manager role, add site admin? • Prevent site admin from gaining manager role? • Should control panels use same registry as sharing tab? I don't think the manager role appears on the sharing page. Anyway, it's a valid concern which I'll find a way to address. • 10888 (Make KSS optional) • Quick consensus • Selenium testing • KSS does this. Plone doesn't. Do we require plip to add this for rewritten work? • Approved Don't worry; if the work we do isn't tested we haven't done the job right. • 10778 (Stand-alone UUID) • Required step toward allowing Dexterity to work well in a Plone site • Community confusion that IntIds are unique identifiers, needs to be corrected • Exist as a well-used add-on that Dexterity depends on Dexterity doesn't depend on plone.app.uuid yet. • 9327 (Unified interface for lists of content) • Very useful for integrators • Being used by search results, collections PLIPs • Yes, but if the PLIPs depending on this don't make it through, likely not to include it. • Approved Will the existing folder listing templates be updated to use the new API? Doing so might be difficult to do without breaking backwards compatibility, but not doing so makes the word unified in the title a bit of a misnomer, and reduces the value of this (makes it one more thing to learn, instead of a replacement that is easier to learn). -- David Glick Web Developer davidgl...@groundwire.org 206.286.1235x32 Groundwire: You Are Connected http://groundwire.org ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
Hi folks, A few comments on things I'm involved in. • 9473 (z3cform) • Ross: Better than Archetypes at form generation, better documentation than formlib, but still requires a lot of knowledge of the internals to work with. • (Small?) improvement over formlib, extensive (but not very approachable) documentation. • Approachability can be improved with layers on top: autoform, dexterity. • Heavy Plone adoption will likely lead toward better documentation. I started writing some quite extensive, Plone-oriented, tutorial-style documentation on plone.directives.form (the Grok-like way to build z3c.form forms). I think it'd be quite feasible to copy this and change it to cover the more traditional plone.app.z3cform. At the moment, it's about 80% complete, but a big project + the new edition of my book got in the way. If anyone is willing and able to run with this, I'd be happy to assist. • plone.app.registry makes it largely transparent • Approved • 9472 (plone.app.registry) • Is a win for persistent settings storage • Form proxying makes it easy • It just works • Needs ui work I'd like to know what UI work it needs at this point. The portal_registry UI is basic, for sure, but functional, moderately good looking, and works pretty efficiently now that we have p.a.jquerytools overlays. It'd be nice to have a JavaScript based substring match search, perhaps. Beyond that, though, proper UI should go into dedicated control panels (which p.a.registry helps you build) • Approved • 10776 (Zope 2.13) • Keep up with Zope, don't get behind like we did in the past • WSGI support: Is it ready yet? It's You mean it is? If so: w00t! • 10846 (plone.testing/plone.app.testing) • Looks great • Do we say this is the best practice? • Wait • Just including this in our KGS for now should steer people towards it +1 to this sentiment • Eat our own dogfood. Implement some core package tests using this. • Does this need its own PLIP? • We're opening the door for that to show up in the future. • Great 2010 conf sprint topic I suggest we just encourage new packages for 4.1 and onwards to use it. I'd be happy to make plone.[app.]uuid use this, for example. • PLIP could make it clearer how best to encourage movement to new framework over existing framework I think this needs wider discussion first, but agreed. • Approved • 10778 (Stand-alone UUID) • Required step toward allowing Dexterity to work well in a Plone site • Community confusion that IntIds are unique identifiers, needs to be corrected • Exist as a well-used add-on that Dexterity depends on Well, not yet, but soon - especially if #9938 makes it - see below. • It's definitely necessary functionality, but is it worthwhile in 4.1 if nothing in 4.1 using it? • Do we say This is great, please make the package. We'll include it later, when it's in use. ? • Martin's never been afraid to create new packages • Looking for our blessing as the designated way forward? • Small change to Plone (catalog index) • Held I think my reason for wanting it in the core, is twofold: - There's a proliferation of half-solutions to this problem right now. We need something blessed that people feel safe relying on. There is a cost associated with each half-solution in terms of catalogue bloat and in terms of confusion. - It's difficult for third party packages to depend on this kind of thing (as we saw with zope.intid), because to be useful, it requires a new catalogue index and a full re-index on existing sites. That's the kind of thing that people may expect in a Plone .x release, but not necessarily just to install a product that happens to depend on it. • 9938 (Factor custom output transforms out of editors) • Yes! • Why don't we do this already? • Reduces risk (listed risk is more of a deliverable. ;) ) • Approved I think if we do this, we should also do #10778. One of the big things I really, really want is proper link-by-uid for Dexterity content. We can't do that if the link-by-uid transforms use Archetypes' UID(), and making a new, future-oriented package for this that's tied to AT seems like a step backwards and an invitation for future migration pain (uid links end up being embedded in content, after all). Martin ___ Framework-Team mailing list
[Framework-Team] Merging strategy for many PLIPs
In the 4.0 cycle, PLIP branches were merged in one 'big bang' after our implementation review. It was a painful process last time, with 30 PLIPs I don't think it will realistically work this time. Instead of a single deadline, I propose that we ask PLIP implementors to submit their PLIP for implementation review and merging as soon as their PLIP is ready - many are already close to complete as they rolled over from 4.0. At an appropriate point we'll draw the line and the remaining PLIPs will be retargeted at 4.2 (with their in-principal approved status kept.) I think this could help better spread the load on us (and in particular on Eric.) Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meet ing Minutes– 17 August, 2010
Le 18/08/10 07:39, Eric Steele a écrit : • 10888 (Make KSS optional) • Quick consensus • Selenium testing • KSS does this. Plone doesn't. Do we require plip to add this for rewritten work? Short: This plip is a chance for the FWT to give a strong push in the right direction by REQUIRING AUTOMATED tests for JS code. Longer: Plone runs more and more js code (iow in the browser), too much being untested (AFAIK). It is time to require automated tests for new JS code added to Plone core; both js unit and functional (selenium or windmill) tests. It would be an opportunity for the community to experiment and decide on best practices in this context. We need these experience and tests as we plan to integrate more complex code (iow code easier to break) like the foreseen Deco editor. I'd be happy to participate to a sprint focused on setting up those practices and building a set of tests for existing JS code. However, I am not proposing to pull the community : I tried at various sprints and miserably failed. Regards -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
On 8/18/10 7:35 AM, Godefroid Chapelle wrote: Le 18/08/10 07:39, Eric Steele a écrit : • 10888 (Make KSS optional) • Quick consensus • Selenium testing • KSS does this. Plone doesn't. Do we require plip to add this for rewritten work? Short: This plip is a chance for the FWT to give a strong push in the right direction by REQUIRING AUTOMATED tests for JS code. Longer: Plone runs more and more js code (iow in the browser), too much being untested (AFAIK). It is time to require automated tests for new JS code added to Plone core; both js unit and functional (selenium or windmill) tests. It would be an opportunity for the community to experiment and decide on best practices in this context. We need these experience and tests as we plan to integrate more complex code (iow code easier to break) like the foreseen Deco editor. I'd be happy to participate to a sprint focused on setting up those practices and building a set of tests for existing JS code. However, I am not proposing to pull the community : I tried at various sprints and miserably failed. Godefroid, I am definitely interested to learn from your experience in this area. Regarding functional testing of Javascript, would you recommend looking at KSS to see how it is done there, or are there newer best practices that have emerged since those tests were written? peace, -- David Glick Web Developer davidgl...@groundwire.org 206.286.1235x32 Groundwire: You Are Connected http://groundwire.org ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team M eeting Minutes– 17 August, 2010
Hello, • 10888 (Make KSS optional) • Quick consensus • Selenium testing • KSS does this. Plone doesn't. Do we require plip to add this for rewritten work? Short: This plip is a chance for the FWT to give a strong push in the right direction by REQUIRING AUTOMATED tests for JS code. Longer: Plone runs more and more js code (iow in the browser), too much being untested (AFAIK). It is time to require automated tests for new JS code added to Plone core; both js unit and functional (selenium or windmill) tests. It would be an opportunity for the community to experiment and decide on best practices in this context. We need these experience and tests as we plan to integrate more complex code (iow code easier to break) like the foreseen Deco editor. I'd be happy to participate to a sprint focused on setting up those practices and building a set of tests for existing JS code. However, I am not proposing to pull the community : I tried at various sprints and miserably failed. Godefroid, I am definitely interested to learn from your experience in this area. Regarding functional testing of Javascript, would you recommend looking at KSS to see how it is done there, or are there newer best practices that have emerged since those tests were written? from his recent work on Canonical, I'm sure Sidnei has some great insights to share here, don't you Sidnei? :-) -- Dorneles Treméa Enfold Systems http://www.enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 211 Skype dtremea ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes– 17 August, 2010
On 18-08-2010 08.07, Martin Aspeli wrote: • 10778 (Stand-alone UUID) I think my reason for wanting it in the core, is twofold: - There's a proliferation of half-solutions to this problem right now. We need something blessed that people feel safe relying on. There is a cost associated with each half-solution in terms of catalogue bloat and in terms of confusion. We have repeatedly had frustration with the lack of a unified UID system that we can depend on when writing add-ons. To base something on it as a developer, you need to know you can depend on it being available always. I don't think it makes sense to postpone it because nothing uses it yet. -- Geir Bækholt www.jarn.com/baekholt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
On 19 August 2010 06:47, Geir Bækholt pl...@baekholt.com wrote: On 18-08-2010 08.07, Martin Aspeli wrote: • 10778 (Stand-alone UUID) I think my reason for wanting it in the core, is twofold: - There's a proliferation of half-solutions to this problem right now. We need something blessed that people feel safe relying on. There is a cost associated with each half-solution in terms of catalogue bloat and in terms of confusion. We have repeatedly had frustration with the lack of a unified UID system that we can depend on when writing add-ons. To base something on it as a developer, you need to know you can depend on it being available always. I don't think it makes sense to postpone it because nothing uses it yet. Right - I think it becomes a bit of a chicken and egg problem otherwise. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
On 19 August 2010 09:20, Martin Aspeli optilude+li...@gmail.com wrote: On 19 August 2010 06:47, Geir Bækholt pl...@baekholt.com wrote: On 18-08-2010 08.07, Martin Aspeli wrote: • 10778 (Stand-alone UUID) I think my reason for wanting it in the core, is twofold: - There's a proliferation of half-solutions to this problem right now. We need something blessed that people feel safe relying on. There is a cost associated with each half-solution in terms of catalogue bloat and in terms of confusion. We have repeatedly had frustration with the lack of a unified UID system that we can depend on when writing add-ons. To base something on it as a developer, you need to know you can depend on it being available always. I don't think it makes sense to postpone it because nothing uses it yet. Right - I think it becomes a bit of a chicken and egg problem otherwise. Also: If we do the PLIP to separate out link-by-UID and similar transforms, that's a natural candidate to use these UUIDs. :) Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
On Wed, Aug 18, 2010 at 5:21 PM, Martin Aspeli optilude+li...@gmail.com wrote: On 19 August 2010 09:20, Martin Aspeli optilude+li...@gmail.com wrote: On 19 August 2010 06:47, Geir Bækholt pl...@baekholt.com wrote: On 18-08-2010 08.07, Martin Aspeli wrote: • 10778 (Stand-alone UUID) I think my reason for wanting it in the core, is twofold: - There's a proliferation of half-solutions to this problem right now. We need something blessed that people feel safe relying on. There is a cost associated with each half-solution in terms of catalogue bloat and in terms of confusion. We have repeatedly had frustration with the lack of a unified UID system that we can depend on when writing add-ons. To base something on it as a developer, you need to know you can depend on it being available always. I don't think it makes sense to postpone it because nothing uses it yet. Right - I think it becomes a bit of a chicken and egg problem otherwise. Also: If we do the PLIP to separate out link-by-UID and similar transforms, that's a natural candidate to use these UUIDs. :) Though I voted against the inclusion of the UUID PLIP on it's own, if the link-by-uuid PLIP makes good use of it, then it certainly could be worth including. If there were a PLIP to make AT compatible with this implementation and convert Plone to using it, that would be a highly compelling argument for its inclusion. Otherwise we end up with Plone directly using one non-deprecated UID API while promoting another (which happens to not be useful anywhere within Plone itself). Don't we already suffer from enough of this kind of framework-level confusion? By including this wouldn't we essentially be saying, Martin made this, and we think it's a nice thing; so now it's part of the core? What other nice little libraries should we make part of Plone just because they might be useful to some developers or are used by a few add-ons that we happen to like? I'm sure we could think of quite a few, but I also think there's a good reason we don't generally do this. Adopting a library that we don't actually use, promotes a vision of Plone as a pure framework/toolkit that I'm not entirely comfortable with. Plone is an application (though a highly extensible one), and I don't really think we should be in the business of providing APIs beyond those consumed by it and those used to customize it. Alec ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
Hi Alec, On 19 August 2010 09:52, Alec Mitchell ap...@columbia.edu wrote: Though I voted against the inclusion of the UUID PLIP on it's own, if the link-by-uuid PLIP makes good use of it, then it certainly could be worth including. I'd like to work with David to make sure that happens. It seems like an obvious win. If there were a PLIP to make AT compatible with this implementation and convert Plone to using it, that would be a highly compelling argument for its inclusion. I think Plone using it should mean the link by UID mechanism in the first instance. I'd like to experiment with making the AT UID() and reference/UID catalogs use plone.uuid as well. Certainly, that's where I'd like us to end up. I just didn't want to be too ambitious with the PLIP in the first instance, in case we end up with complicated migrations or BBB issues. Of course, plone.uuid on its own works perfectly well with Archetypes objects. The problem is that as it's written right now, it doesn't care about the AT UID() method and related catalogues. One thing we probably could do, is to make the Archetypes make_uuid() method use the same UUID algorithm as plone.uuid. I'm not sure if we'd want to migrate old content. They probably shouldn't clash, and making changes could be problematic in case of embedded link-by-uid references and similar. We could also/instead make an IUUID adapter implementation for Archetypes content that looked context.UID(), and let AT continue to manage its own UUIDs (but ideally using the same UUID generating algorithm) to bridge the two. We could make the UUID indexer use the UID catalogue index instead of creating a new one. This would be more consistent, at least if the UUIDs looked and worked the same. If there's appetite for this type of a change, I'd be happy to implement it. Otherwise we end up with Plone directly using one non-deprecated UID API while promoting another (which happens to not be useful anywhere within Plone itself). Don't we already suffer from enough of this kind of framework-level confusion? I guess it depends on your point of view. To me, we don't actually have proper UUID mechanism at present. Archetypes has a UID() method, which exposes an ID that's principally used as an implementation detail of its reference engine. That reference engine (and by extension the UID() method and the way in which it generates UUIDs) is tightly bound to AT's base classes and virtually impossible to use elsewhere. You can't have these kinds of UID's on comments, for example, or on portlets, or on the Plone site object, or on any non-AT content (e.g. using Dexterity). I wrote the PLIP because I'm uncomfortable with the status quo. People end up making their own half-solutions, e.g. using their own counters, physical paths (which are not stable), keeping their own BTrees of content, using zope.intid or faking up the UID() method in a way that isn't quite compatible with how AT uses it. By including this wouldn't we essentially be saying, Martin made this, and we think it's a nice thing; so now it's part of the core? What other nice little libraries should we make part of Plone just because they might be useful to some developers or are used by a few add-ons that we happen to like? I'm sure we could think of quite a few, but I also think there's a good reason we don't generally do this. I agree with this, and I'm really not shy about keeping packages as non-core dependencies. In this case, though, I think there are compelling reasons to have a single API that is exposed as a service by the core of Plone, as outlined in my original message above. Adopting a library that we don't actually use, promotes a vision of Plone as a pure framework/toolkit that I'm not entirely comfortable with. Plone is an application (though a highly extensible one), and I don't really think we should be in the business of providing APIs beyond those consumed by it and those used to customize it. I think we should be in the business of making Plone useful to customers and integrators. Right now, our story for uniquely identifying content and other objects (e.g. comments) sucks. It feels half-baked compared to other CMS's. It makes it difficult to build services on top of Plone that need to uniquely identify content. In my previous project, here's where the lack of a proper UUID hurt: - We needed to write migrations, and we needed to identify already-imported content to update or ignore - We needed link-by-UID for non-AT content - We needed to embed some content references in hidden form fields. A UUID would've been a natural token here. - We wanted to expose certain things over web services that needed a short token to identify particular content items, which would be stable even if those items were moved I know others have had similar concerns. It's difficult to work on multilingual non-AT content, for example, without having a good UUID implementation. Some of the web services
