Ticket #9472 (closed PLIP: fixed)
Include plone.app.registry
Reported by: | erikrose | Owned by: | optilude |
---|---|---|---|
Priority: | major | Milestone: | 4.1 |
Component: | General | Version: | |
Keywords: | Cc: | plip-advisories@… |
Description (last modified by erikrose) (diff)
This is a pseudo-PLIP where we can collect pros and cons of including plone.app.registry (as desired by #9295 and others) in Plone 4.
Dependencies
- plone.app.z3cform
- plone.supermodel, which creates schema interfaces from (and exports them to) XML, like this:
from plone.supermodel import xmlSchema IMySchema = xmlSchema("myschema.xml")
Pros
- Over propertysheets: registry has a dict API more interoperable with the rest of Python (and easier to remember):
>>> registry['plone.records.tests.cms'] u'Plone' >>> registry['plone.records.tests.cms'] = u"Plone 3.x"
- Over raw schema: because registry limits stored data to a few simple types, you can uninstall a product, and any data left behind doesn't cause errors due to schema classes not being found.
- You're not limited to defining registry records using GenericSetup XML; you can use Z3 schemas as well, if you stick to simple field types.
Cons
- Necessary migrations and/or backward-compatibility code
- Pulls in z3c.form, which might have its own problems. Hanno hints dependency might be removable.
Change History
comment:2 Changed 7 years ago by erikrose
I'm +1 if we can excise z3c.form (and maybe if we can't, depending on what happens with #9473). I think this might be a helpful step on the way to a more stateless installation mechanism.
comment:3 Changed 7 years ago by erikrose
- Description modified (diff)
Linked to available registry field types.
comment:7 Changed 6 years ago by vincentfretin
I changed the i18n domain of plone.app.registry to plone. 11 new messages have been added to plone.app.locales.
comment:8 Changed 6 years ago by 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.
comment:9 Changed 6 years ago by optilude
Framework team -
I think this PLIP is "ready", since it's more of a dependency consideration exercise. We can obviously add plone.app.z3cform/plone.z3cform to the KGS at any time, but I don't see the need for another branch. More likely, the z3c.form control panel PLIP or the plone.app.discussion PLIP will drive the merging of this.
Do you agree?
Martin
comment:10 Changed 6 years ago by optilude
Sorry - got my PLIPs mixed up, but the same applies to plone.registry/plone.app.registry: They should get added to the KGS when something that depends on them (p.a.discussion, most likely) depends on them.
I would, however, want to wait until the next release of p.registry/p.a.registry, which optimises the ZODB storage of registry records. This requires (trivial/on-the-fly) migration from older versions.
That code is ready, but I've asked Laurence to review it before I merge it to trunk and make new releases.
Martin
comment:11 Changed 6 years ago by hannosch
I think any plip should have a standard plip buildout file. The framework team is supposed to review the code, run the tests, make sure something installs... which is all easier with a buildout to start from. The plip submitter usually knows best how to write this buildout file and what exact versions should be used.
comment:12 Changed 6 years ago by optilude
comment:13 Changed 6 years ago by optilude
The buildout in the revision above should allow for this to be reviewed.
If accepted, merging tasks include:
- Add plone.app.registry as dependency of Plone package (if desired?)
- Add profile-plone.app.registry:default as an install dependency of the Plone GenericSetup profile (if desired?)
- Rewrite tests to use plone.app.testing instead of collective.testcaselayer (depends on #10846)
Martin
comment:14 Changed 6 years ago by optilude
comment:15 Changed 6 years ago by optilude
comment:16 Changed 6 years ago by robgietema
comment:17 Changed 6 years ago by cah190
comment:19 Changed 6 years ago by cah190
The FWT would like to see a ZMI-level editor for the eventuality when critical settings are stored in the registry that could lock a user out of the Plone-level registry editor by preventing the Plone UI from being rendered. I created ticket #11166 to cover the concern, as this PLIP is likely to be accepted for merging and having the editor will not be considered a blocker.
comment:20 Changed 6 years ago by davisagli
Another option might be using the "failsafe main_template" fallback pattern I implemented for plone.app.themeeditor to address a similar concern: http://svn.plone.org/svn/plone/plone.app.themeeditor/trunk/plone/app/themeeditor/browser/failsafe_main_template.pt (and related view code in console.py)
comment:21 Changed 5 years ago by esteele
comment:22 Changed 5 years ago by esteele
- Status changed from new to closed
- Resolution set to fixed
Merged.
comment:23 Changed 5 years ago by davisagli
- Status changed from closed to reopened
- Resolution fixed deleted
The implementation of this PLIP is not complete -- there is no upgrade step to install plone.app.registry if it wasn't installed as an add-on in Plone < 4.1. See #12184
comment:24 Changed 5 years ago by optilude
- Status changed from reopened to closed
- Resolution set to fixed
Let's not reopen the PLIP ticket. A defect's a defect. 4.1 is long gone, so there's no value in having this ticket open.