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@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
