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

zopyx commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

datakurre commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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

jensens commented 8 years ago

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

zopyx commented 8 years ago

I did not commit to work on the removal.

2016-11-06 13:35 GMT+01:00 Jens W. Klein notifications@github.com:

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 commented 6 years ago

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

hvelarde commented 6 years ago

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

plone / Products.CMFPlone