Products.cmfplone: PLIP: remove support for old style resource registries in Plone 5.2

[zopyx]

Proposer: Andreas Jung

Seconder: Jens W. Klein

Abstract

Remove/disable support for old-style resource registries (cssregistry.xml and jsregistry.xml) completely.

Motivation

With Plone 5.1 the support for old-style CSS and Javascript registrations (cssregistry.xml and jsregistry.js) should be dropped completely. Any code/add-on trying to register or update a GenericSetup profile containing such configurations should raise an exception. Besides a speaking error message why the exception occurs ("your using an old-style configuration...") the message should indicate how to proceed instead (e.g. a link to the new-style registry docs). An explicit failure is better here than silently ignoring those files or just logging of the failure.

Reasons

Dealing with old-style registrations in the context of the new Plone resource registry implementation in terms of the "plone-legacy" bundle has been broken throughout the complete Plone 5.0 releases. Many of these issues are documented on Github and various postings of mine on community.plone.org. The overall impression is that there is no reasonable solution for fixing the handling of old-style registrations for Plone 5. Fixes are more workarounds and appear like duct-type fixes. Every Plone 5.0.x brought new problems with the support of legacy registrations.

Integrators and maintainers of legacy code need a clear story how to deal with their old code when they need to move forward Plone 5. Javascript and in particular support for arbitrary thirdparzy Javascript modules is essential and crucial nowadays. Although the support for thirdparty Javascript modules in Plone 5 through the new resource registries implementation is still tricky, partly fragile and not consistent, removing another fragile way doing things in Plone is in the interest of every integrator (saving money, resources and motivation).

Proposal & Implementation

There is no reference implementation for this PLIP. As a first step it should be sufficient to add checks to the exisiting resource registry code base that deals with the plone-legacy bundle or deals with the import of the related XML configuration files. In a later step the codebase could be cleaned up by removing all plone-legacy bundle related code.

Risks

This PLIP will clearly break all-ons that would possibly work with Plone 5.0 with the plone-legacy bundle approach. However there is no way to make the legacy bundle approach work under all circumstances. Stability and consistent behavior of the Plone installation is king - both for end-users, developers and integrators - in particular a must for an enterprise-grade CMS.

Deliverables

• PR removing/disabling cssregistry.xml and jsregistry.xml
• Documentation how migrate old code and old-style registrations to the new Plone 5 RR implementation. The documention partly exists.

• The current RR implementation is still fragile to use in particular because of RequireJS. There is no canonical way for integrating a particular JS addon with Plone. It is very easy to break the resource registry with thirdparty JS addons or your own code. Note that many integrators in particular ppl from outside the Plone core developer community are not Javascript experts (including the author) and are not familar with all aspects of modern Javascript development including RequireJS, the Javascript tool chain and packaging story. The requirement here is: you need a particular JS addon in Plone providing some functionality required by business constraints. You want to include and use this add-on easily in Plone with being an expert. You read the installation docs of a particular JS add-on and you want and expect it to work exactly in the same way in Plone 5.

  Participants

• Andreas Jung

[hvelarde]

I think this must be done after #1406 is implemented; I also think that features for 5.1 are already defined so maybe this will have to wait until 5.2.

[zopyx]

Waiting for 5.2 means at least another year of brokenness and inconsistent behavior. There should be a clear and documented way how to do right _now_ and not at some point in the future.

[hvelarde]

IMO, smaller, less ambitious releases are faster to achieve and preferable all the time; but let's wait to see what the @plone/framework-team thinks about this; I'm +1 on your proposal.

also, lessons have to be learned from this broken feature: instead of trying to re-implement the legacy bundle using the new resource registry, we should have left the old resource registry usable as described in https://github.com/plone/Products.CMFPlone/issues/1663#issuecomment-231205720.

[zopyx]

If someone need to touch an add-on for Plone 5 then it should be sufficient to do the work once instead of adjust some code now to Plone 5 and having the need to move registry information at a later release...I don't want to see such API changes in a .2 release...stuff should be stable after 5.1..it's ok for me to change it now in a .1 release based on experience made with 5.0 but not for 5.2 IMO

[jensens]

I think we will discuss this at the next framework team meeting.

[datakurre]

I think this would help those, who really want to make add-one supporting both Plone 4 and 5, because then the package could trivially have separate resource files and registrations for both versions in a single profile.

[datakurre]

@hvelarde I've now submitted a possible implementation (https://github.com/plone/plone.app.registry/pull/24) for https://github.com/plone/Products.CMFPlone/issues/1406, so it should no longer be a blocker for this.

[thet]

Title changed from: PLIP: remove/disable plone-legacy bundle support in Plone 5.1
To: PLIP: remove support for old style resource registries in Plone 5.1

Plone legacy bundles are still handy.

[ebrehault]

@zopyx this PLIP has been approved by the @plone/framework-team

[jensens]

I second this. Removal should be easy. @zopyx do you already have some branch where I can try code / help with this task?

[zopyx]

I did not commit to work on the removal.

2016-11-06 13:35 GMT+01:00 Jens W. Klein [email protected]:

I second this. Removal should be easy. @zopyx https://github.com/zopyx
do you already have some branch where I can try code / help with this task?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/plone/Products.CMFPlone/issues/1742#issuecomment-258678199,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkRP3qxp5QvPU3-NbK-AWF-yXcgtC1eks5q7cl9gaJpZM4Jzclf
.

[jensens]

parts solved by https://github.com/plone/Products.CMFPlone/pull/2573

[hvelarde]

just for the record: an alternate method for registering static resources in Plone add-ons that works in both Plone 4 and 5 is described here:

http://hvelarde.blogspot.com/2018/09/look-ma-no-resource-registries.html