Proposer : Johannes Raggam
Seconder : None by yet
PLIP configuration: https://github.com/plone/buildout.coredev/blob/5.2/plips/plip-1653-staticresources.cfg
Repos:
Abstract
This PLIP is about the separation of Plone's static resources from CMFPlone.
Plone's own bower components directory (Products.CMFPlone.static.components) is hard to understand, maintain and keep up to date.
While all patterns reside in mockup the toolbar pattern and After the deadline TinyMCE plugin are still kept in CMFPlone.
The static resources take a lot of disc space, fill up the git history and make searching in files cumbersome.
This PLIP proposes to seperate those static resources from CMFPlone into a dedicated package plone.staticresources.
Motivation
-
Complexity - many related resources are spread over different packages and directories. This makes the current structure hard to understand.
-
Maintainability - It's cumbersome, errorprone and easy to forget to keep bower.json in CMFPlone and mockup in sync.
-
Depending on a specific version of static resource bundles (via bower, npm or python version specifiers) would even be easier if we do not maintain two similar repositories.
-
The process of upgrading CMFPlone static resources and just keeping the minimal necessary set excluding unused thing like test and demo files is difficult (includes maintaining the .gitignore file)
-
The static resources fill up a lot of space in CMFPlone. The static directory counts currently 91MB.
-
Each change to the static directory (e.g. updating the components directory) adds to the git history.
-
Searching within files is cumbersome - if you do not exclude the static directory or explicitly include only python files, most of the hits come from the static directory.
-
All Plone related patterns live in mockup - so should the toolbar pattern. It's more likely that it gets more attention than being in CMFPlone. And mockup (or maybe even more patternslib) IS the best-practice resource of creating patterns.
Proposal & Implementation
-
Create a new package plone.staticresources.
-
Move the toolbar pattern to mockup.
-
Create a npm package for mockup.
-
Create a npm package for patternslib.
-
Manage those two dependencies and all other via npm.
-
Git-include the node_modules resource directory.
-
Register necessary resources as plone static resources or browser resources, like it was done in CMFPlone.
-
Register all resources via registry.xml, like it was done in CMFPlone.
-
These changes include the plone and plone-logged-in bundles also.
-
Remove the resource registration in registry.xml, the plone static resource and browser resource registrations as well as all resource files from CMFPlone.
-
Remove resource registrations from mockup, as this is now done in plone.staticresources and make mockup a JS-only package by removing all Python related setup code.
-
Raise versions for CMFPlone to 5.2 and mockup to 3.0.
Risks
Low risks, as all resource paths keep the same (++resource++mockup, ++resource++plone).
The node_modules directory should be provided as components, as like the current bower directory as like the current bower directory, to be able to keep the same paths like before.
Metadata
Updated version from 2017-02-21.
/cc @davilima6 @agitator @plone/framework-team
Proposer : Johannes Raggam
Seconder : None by yet
PLIP configuration: https://github.com/plone/buildout.coredev/blob/5.2/plips/plip-1653-staticresources.cfg
Repos:
Abstract
This PLIP is about the separation of Plone's static resources from CMFPlone.
Plone's own bower components directory (
Products.CMFPlone.static.components) is hard to understand, maintain and keep up to date.While all patterns reside in mockup the
toolbarpattern andAfter the deadlineTinyMCE plugin are still kept in CMFPlone.The static resources take a lot of disc space, fill up the git history and make searching in files cumbersome.
This PLIP proposes to seperate those static resources from CMFPlone into a dedicated package
plone.staticresources.Motivation
Complexity - many related resources are spread over different packages and directories. This makes the current structure hard to understand.
Maintainability - It's cumbersome, errorprone and easy to forget to keep bower.json in CMFPlone and mockup in sync.
Depending on a specific version of static resource bundles (via bower, npm or python version specifiers) would even be easier if we do not maintain two similar repositories.
The process of upgrading CMFPlone static resources and just keeping the minimal necessary set excluding unused thing like test and demo files is difficult (includes maintaining the .gitignore file)
The static resources fill up a lot of space in CMFPlone. The static directory counts currently 91MB.
Each change to the static directory (e.g. updating the components directory) adds to the git history.
Searching within files is cumbersome - if you do not exclude the static directory or explicitly include only python files, most of the hits come from the static directory.
All Plone related patterns live in mockup - so should the toolbar pattern. It's more likely that it gets more attention than being in CMFPlone. And mockup (or maybe even more patternslib) IS the best-practice resource of creating patterns.
Proposal & Implementation
Create a new package
plone.staticresources.Move the
toolbarpattern tomockup.Create a npm package for
mockup.Create a npm package for
patternslib.Manage those two dependencies and all other via
npm.Git-include the
node_modulesresource directory.Register necessary resources as plone static resources or browser resources, like it was done in CMFPlone.
Register all resources via
registry.xml, like it was done in CMFPlone.These changes include the
ploneandplone-logged-inbundles also.Remove the resource registration in registry.xml, the plone static resource and browser resource registrations as well as all resource files from CMFPlone.
Remove resource registrations from mockup, as this is now done in
plone.staticresourcesand make mockup a JS-only package by removing all Python related setup code.Raise versions for CMFPlone to 5.2 and mockup to 3.0.
Risks
Low risks, as all resource paths keep the same (
++resource++mockup,++resource++plone).The
node_modulesdirectory should be provided ascomponents, as like the current bower directory as like the current bower directory, to be able to keep the same paths like before.Metadata
Updated version from 2017-02-21.
/cc @davilima6 @agitator @plone/framework-team