You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The basic components of Volto are being extracted. Classic UI should make use of this where it makes sense, so we have a shared effort.
Motivation
We don't want to maintain two different code bases for parts that mostly do the same things.
Assumptions
Classic UI will still be server side rendered: there is only a Python process, no Node process (Razzle).
We should only do this for parts where it is fine to have no non-javascript fallback, so parts where we can basically deliver an empty content area, because SEO is not needed.
Proposal & Implementation
For the following Classic UI parts it may make sense to use the Volto components:
Folder contents. This is already a very dynamic view that gets rendered once and then all the clicks are handled dynamically.
Sharing tab
Collections edit form
Maybe the toolbar
Control panels. Bonus: this avoids needing to think about where we will move the existing control panel code, because we can then just remove it in Plone 7.
A few control panels are missing in Volto, see this list. The list was started in 2017, not sure how up to date it is. From the top of my head I know that the Discussion and Caching control panels are missing.
Some control panels are only needed in Classic UI, at least the Resource registry and Theming.
This does not have to be done all at once of course.
Simple original control panels that are only a wrapper around some registry settings in an Interface could still be done the old way. The plone.app.registry control panel form wrapper would stay as a simple means for Classic UI add-on authors to use.
Deliverables
Risks
If we need new parts from Volto and still existing parts from Classic UI, the bundle size may increase.
This makes plone.restapi a hard dependency of plone.classicui.
It should still be possible to create a basic site with only Products.CMFPlone. But that would not have any control panels, or at least it would have less. The add-ons control panel may need to stay, otherwise there would be no way to start with Products.CMFPlone and later add plone.classicui. (We will need to think carefully about which scenarios we can reasonably support here.)
As discussed yesterday in the open space, there are (and will be more) potential parts of volto which should be reused in Classic-UI in order to avoid duplicated effort for the same tasks. We need to discuss this in the next Classic-UI meeting (Dec 11, 2024).
Personally I would not tend to replace backend rendered parts completely with volto components (eg. controlpanel) but as a first step, there are already dynamic parts (folder_contents, selects, ...) which totally make sense to be replaced with volto components because they are really outdated.
I'm willing to lead this ... will add myself here.
Offtopic: In general there should be a main discussion round about our Vision for Classic-UI for Plone 7 and beyond.
PLIP (Plone Improvement Proposal)
Responsible Persons
Proposer: Maurits van Rees
Lead: Peter Mathis
Abstract
The basic components of Volto are being extracted. Classic UI should make use of this where it makes sense, so we have a shared effort.
Motivation
We don't want to maintain two different code bases for parts that mostly do the same things.
Assumptions
Proposal & Implementation
For the following Classic UI parts it may make sense to use the Volto components:
This does not have to be done all at once of course.
Simple original control panels that are only a wrapper around some registry settings in an Interface could still be done the old way. The
plone.app.registry
control panel form wrapper would stay as a simple means for Classic UI add-on authors to use.Deliverables
Risks
plone.restapi
a hard dependency ofplone.classicui
.Products.CMFPlone
. But that would not have any control panels, or at least it would have less. The add-ons control panel may need to stay, otherwise there would be no way to start withProducts.CMFPlone
and later addplone.classicui
. (We will need to think carefully about which scenarios we can reasonably support here.)Participants
The text was updated successfully, but these errors were encountered: