Convert control panels to use z3c.form

[hannosch]

Proposer: Hanno Schlichting
Seconder: None as yet

Abstract

Convert all formlib based control panel screens in plone.app.controlpanel to use z3c.form instead. Converting control panels currently not using formlib to z3c.form might be inside the scope of this PLIP, but only actual implementation will show.

Motivation

Our standard control panels, as found in plone.app.controlpanel are implemented using zope.formlib / zope.app.form. While formlib has been helpful to have an Archetypes independent form framework, it has proven to be too inflexible in real customer projects. Learning from the short-comings of formlib, z3c.form has been written and has meanwhile seen a major adoption in the community - both inside the Plone and the wider Zope communities.

The Zope 2 integration of zope.formlib has been moved to a separate package called five.formlib for Zope 2.12. In Zope 2.13 this package isn't shipped anymore. This reflects the dwindling mindshare that zope.formlib has seen. For Plone 5.x this could allow Plone to no longer ship with formlib at all.

Assumptions

This PLIP is dependent on PLIP #9473 - the general readiness of the Plone - z3c.form integration. It assumes that customizations of the Plone control panels are infrequent and changes to the internals of the control panels aren't seen as breaking public API's of Plone.

Proposal & Implementation

The aim of this PLIP is to re-implement all formlib based control panels inside plone.app.controlpanel on top of z3c.form. A new base class for add-on control panels will be provided, so add-ons can opt-in to the new approach. The old formlib based base classes would be deprecated and removed in Plone 5.0.

The implementation will use the plone.app.z3cform and plone.autoform packages. It will not use plone.directives.form and thus avoid a dependency on Grok.

Deliverables

• A branch of plone.app.controlpanel with the new implementation
• Documentation for writing your add-on control panel based on the new classes

The localization strings should be kept as close to the current code as possible, so no major new translation effort will be required. The actual UI should also stay very similar to the current state, so no major end-user documentation changes will be needed.

Risks

This PLIP doesn't consider the risks for including z3c.form itself. Specific risks for this PLIP are seen as minor. Only for the unlikely case that someone has customized the control panels or has code based on one of the specific panels breakage is to be expected. The only known add-on doing this is LinguaPlone, which extends the language control panel. It would be part of this PLIP to ensure LinguaPlone continues to work.

Participants

Hanno Schlichting <hannosch>

Progress

Not yet started.

[davisagli]

I am currently doing some work on adjusting the slots within the main form macros template in plone.z3cform and plone.app.z3cform, to better match the sorts of overrides that are commonly necessary -- see  http://groups.google.com/group/dexterity-development/msg/f4bb45493002bd3e ...so now would be a great time to do enough initial exploration to find out what slots you need in order to support a template for control panel forms, in case there are any other changes we need to make.

[jonstahl]

I think this is a fantastic idea. I do have one friendly amendment: I think it would be smart (esp. if we intend to deprecate formlib in Plone 5) to include within the scope of this PLIP a short document that explains to beginning/intermediate product authors how to convert an existing add-on products control panel configlet to z3c.form. That will help our add-on products make the leap when it is time.

[ldr]

Would it make sense to move to plone.app.registry for setting storage as well? - it makes writing simple control panels ridiculously easy and simplifies the "how do I retrieve a setting" story. Backwards compatibility will be the biggest difficulty there, but might be possible with properties that get/set to the registry.

[hannosch]

Replying to ldr:

Would it make sense to move to plone.app.registry for setting storage as well? - it makes writing simple control panels ridiculously easy and simplifies the "how do I retrieve a setting" story. Backwards compatibility will be the biggest difficulty there, but might be possible with properties that get/set to the registry.

I think it makes perfect sense to convert from portal_properties and custom tools to plone.app.registry in general. But I won't sign up or promise to work on this for 4.1. My next weeks are busy enough as it is, so I cannot afford any feature creep ;)

[esteele]

Your PLIP has been accepted for consideration for Plone 4.1.

Framework Team voting on this PLIP was: Alec +1 Craig +1 Elizabeth +1 Laurence +1 Martijn +1 Matthew +1 Rob +1 Ross +1

The initial implementation deadline for your PLIP is October 1st, 2010. The Framework Team would certainly appreciate you finishing beforehand so that they may begin evaluating it as soon as possible. Announce its readiness here once your implementation is ready for review.

[hannosch]

My Zope 2.13 PLIP is costing me too much time. I'll have to defer this one to Plone 4.2. Less review work for the fwt :)

[rossp]

PLEASE READ THIS AND RE-OPEN VALID PLIPS!

As we launch the new PLIP process we'd like to see which PLIPs:

• are still appropriate/needed
• still have owners/proposers/champions
• still have available implementers

If this PLIP should still be considered for future releases of Plone please do re-open this ticket and assign an appropriate milestone. If it should be considered for the next release of Plone, use the 4.2 milestone. Also be sure to update the PLIP description, requester, owner, etc. and include a comment detailing recent progress and new plans. We will use all these details in the new continuous PLIP process.