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.app.layout, 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) to plone.app.layout, with backwards compatibility in place, also for page templates. Update: move the code to plone.app.layout instead, which will become a core add-on. We keep plone.classicui small: only the distribution plus the dependencies.
• The dependency chain is: Plone -> plone.classicui -> plone.distribution -> Products.CMFPlone.
• 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.

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

[ale-rt]

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.

We are talking to move templates from a package to another one.

This PLIP aims for an improvement, and IMO moving the templates in plone.app.layout does not sound like an improvement at all.

I would consider moving that to:

• either plone.classicui (I think this was the plan when the idea of plone.classicui came out some years ago).
• or to a brand-new package

In the vision of a plone.classicui distribution, the package name plone.app.layout does not convey any special meaning.
The only advantages that it has are that:

• it already exists
• it has already some templates

If you still want to make in clean, there is also the option of creating a brand-new package.

Is this necessary?
I do not see that big of a deal in having the page templates in plone.classicui.

If I look to ploneintranet it also comes in one single repo.
And to my knowledge also volto does that.

I do not see why plone.classicui will benefit from being just a thin layer.

That said:

1. nothing happened since quite a while in the plone.classicui package
2. I am aware that work should be started in the Alpine city sprint
3. whoever has energy/time/money to do this job will in the end have a final saying on this task.

[mauritsvanrees]

In Plone 6.1, plone.classicui lives above Products.CMFPlone as a core add-on. For me this means we cannot move templates there, because then Products.CMFPlone 6.x would lose the functionality provided by these templates. In Plone 7 there would be more freedom.

We need to look at how we want Plone 7 to be structured, and then see how we can already start moving in that direction in Plone 6.x, without breaking stuff (too much).

One way could be to list all templates, or all directories with templates, and see if it makes sense to move them.

Main goal is to get Products.CMFPlone 7 including its dependencies smaller, so Volto sites need less backend code, and there is a bit more freedom for Classic UI code to do major changes. Some thoughts:

• There are templates used for the ZMI, I don't think anyone is advocating moving those. It could be done in specific cases though.
• Not all templates have to be moved. For example Products.CMFEditions has 6 templates (ignoring some more used for the ZMI), but I think it is fine to keep those. Volto is using CMFEditions.
• Portlets are not needed by Volto, but they are already in their own packages, so they don't need to move.
• Volto/plone.restapi uses almost nothing from plone.app.layout. For me it makes sense to look at the few things that restapi does need, and move those somewhere else, like some navigation tree code, and maybe breadcrumbs.
• Products.CMFPlone:
  • controlpanel is for Classic UI only, so could be moved. plone.app.controlpanel anyone? :-)
  • browser/syndication: not sure if Volto uses this after all, or if it has something of its own.
  • browser/templates: this would be the main chunk to move.
  • browser/login: move as well.

[jensens]

I agree with @mauritsvanrees, except for the one with the smiley.

I would like to make portlets a core addon above CMFPlone. Volto does not need them. Classic Plone neither for all use cases.

[1letter]

@jensens what does 'core addon' mean? what is the difference to a 'normal' addon? for me, portlets are not core and can be outsourced to a separate addon.

[mauritsvanrees]

A core add-on is any package that is a dependency of Plone, but not of Products.CMFPlone. So currently this list:

    plone.app.caching
    plone.app.discussion
    plone.app.iterate
    plone.app.multilingual
    plone.app.upgrade
    plone.classicui
    plone.restapi
    plone.volto
    Products.CMFPlacefulWorkflow

[stevepiercy]

@mauritsvanrees @jensens should Above Products.CMFPlone be updated in the docs?

Also the diagram?

[jensens]

@mauritsvanrees @jensens should Above Products.CMFPlone be updated in the docs?

Also the diagram?

we should review it