Ticket #9472 (closed PLIP: fixed)

Opened 5 years ago

Last modified 3 years ago

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:1 Changed 5 years ago by erikrose

  • Description modified (diff)

comment:2 Changed 5 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 5 years ago by erikrose

  • Description modified (diff)

Linked to available registry field types.

comment:4 Changed 4 years ago by esteele

  • Milestone changed from 4.0 to 4.x

comment:5 Changed 4 years ago by ldr

  • Milestone changed from 4.x to 4.1

comment:6 Changed 4 years ago by ldr

  • Owner set to optilude

comment:7 Changed 4 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 4 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 4 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 4 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 4 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 4 years ago by optilude

(In [39240]) Add PLIP buildout for PLIP refs #9472 and refs #9473. This basically allows the framework team to review the relevant code and run the tests. Other PLIPs (z3c.form control panels, discussion improvements) will add functionality that actually use these packages.

comment:13 Changed 4 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 4 years ago by optilude

(In [39246]) Make plone.app.registry use plone.app.testing for test setup. Refs #9472

comment:15 Changed 4 years ago by optilude

(In [39247]) Update to use the correct extra for plone.app.registry. Refs #9472

comment:17 Changed 4 years ago by cah190

(In [40102]) Review for PLIP 9472. Refs #9472.

comment:18 Changed 4 years ago by cah190

  • Cc plip-advisories@… added

comment:19 Changed 4 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 4 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 3 years ago by esteele

(In [46244]) Merge in (related) PLIPs. Refs #9472. Refs #9473. Refs #10846.

comment:22 Changed 3 years ago by esteele

  • Status changed from new to closed
  • Resolution set to fixed

Merged.

comment:23 Changed 3 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 3 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.

comment:25 Changed 22 months ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.