Start separating Classic UI code from the core

[tisto]

PLIP (Plone Improvement Proposal)

Responsible Persons

Proposer: @jensens

Seconder: @mauritsvanrees

Abstract

Step by step move classic ui templates and view-logic to plone.classicui, while keeping the API/business logic in core packages.

Motivation

• Cleaner, easier to maintain code.
• Separation of view-logic and API/business logic makes it easier to re-use code and reduce duplication.
• Smaller core, less memory/disk footprint for users of the Volto frontend which does not need the Classic UI code.

Assumptions

In Plone 6, when you use only Products.CMFPlone, we still want you to get the complete Classic UI, or at least most of it. In Plone 7 the Classic UI is still included with the Plone package, but not with the Products.CMFPlone package. See PLIP #3955 for that part.

Proposal & Implementation

• Have a plone.classicui package.
• This will define the Classic UI Plone distribution, so it will have the code to create a standard Classic UI site.
• Begin moving code that is only for Classic UI (so useless for Volto) in there, with backwards compatibility in place, also for page templates.

In Plone 6.1:

• The wanted dependency chain is: Plone -> plone.distribution -> Products.CMFPlone -> plone.classicui.
• So plone.classicui will have a definition for the Plone Classic UI distribution, but it does not have a hard dependency on plone.distribution.
• When you install only Products.CMFPlone the "Create a new Plone site" will create a Classic UI site in the traditional way, so not using plone.distribution. It could be a bit more basic, because we would prefer not to maintain both the old and new way.

In Plone 7.0, the wanted dependency chain is: Plone -> plone.classicui -> plone.distribution -> Products.CMFPlone. Here the button for "Create a new Plone site" will definitely give a more basic site.

Alternatively, in Plone 6.1 we already put plone.classicui between Plone and Products.CMFPlone. But then we cannot already move templates and browser views there. That would then all have to be done in Plone 7.0.

Deliverables

plone.classicui package and shrunken Plone-core packages (those between (and including) plone.base and Products.CMFPlone).

Risks

• No longer fallback UI for a pure headless Plone (except ZMI)

• Participants

TODO

[mauritsvanrees]

I talked with @ale-rt and @MrTango at the Buschenschanksprint. It feels like the discussion is not completely done, or not unanimous, but my conclusions from there are:

• Let plone.classicui only contain the distribution, nothing more.
• plone.classicui will always depend on Producst.CMFPlone, not the other way around.
• If we want to start moving templates, they can go to plone.app.layout, as that feels like a really Classic UI only package. Some parts should be moved out of there if they are needed by Volto. In Plone 7 plone.app.layout would then live above Products.CMFPlone and be pulled in by plone.classicui.

An alternative package name could be plonedistribution.classicui (or plonedistro.classicui), and then plonedistribution.volto to be on top of plone.volto. The idea would be that plone.volto already has too much code, and for a distribution it is best to be a very light package, just like the current Plone package has no real code. But I am not much a fan of adding yet more packages.

[jensens]

I agree to have a small plone.classicui package and use plone.app.layout as the bucket for all layout/ui/template related. I tend to not add more packages. The other way around, features in plone.volto could be moved elsewhere, because meanwhile its very bloated. But that's OT here.

[tisto]

I approve this PLIP. cc @plone/framework-team @plone/release-team