As Hector mentioned in his PLIP, there are already some other PLIPs
targeting simplifying the resource registry (LESS controlpanel PLIP,
removal of old-style resource registry).
I would add two more resource registry improvement ideas - but maybe
these are better done as PLIPs directly instead in a comment to Hectors
PLIP:
- PLIP to get rid of the necessity of declaring bundle-resources in
order to define a bundle
- PLIP to make sure, unique URL hashes get automatically invalidated
after filesystem or plone.resource resources have changed, so that
last_compilation gets obsolete. (Jens has done some work here, but I'm
not sure how far he finally got there)
imagine a PLIP to disable meta-bundling in production mode.
Isn't that already the case?
Products.CMFPlone.interfaces.resources.IBundleRegistry.merge_with lists
as possible vocabulary items "", "default" and "logged-in". Isn't the ""
value in fact a disable meta bundle value?
Anther thing worth fixing with meta_bundling is, that AFAIK it still has
some issues with replacing / resolving URL references. The
less-plugin-inline-urls helps with images, but not fonts. Not sure about
details, but I had at least some issues here...
Ordering resources according the registry order could be done via a
PR (no need for a PLIP here).
Ordering of require JS resources is pointless.
Correct order of legacy scripts / non-compile scripts is necessary. Is
it really the case, that those resources are not spit out in the correct
order?
we could rename “bundle” into “resource” and “resource” into
“resource item” (or “resource component”)
sounds worth to think about...
Best,
Johannes
Hi all,
As I was finalizing the today's meeting minutes, I thought the Resource
registry PLIP deserved a more precise answer.
As I do not want to speak in your name without your approval, please
https://docs.google.com/document/d/18CPPvIoao2_jUZMNuuq35VLUVHv-RaPlFsK5bRwYJuE/edit#
Feel free to change it the way you want, I will publish it on
community.plone.org <http://community.plone.org> tomorrow afternoon.
Eric
_______________________________________________
Framework-Team mailing list
https://lists.plone.org/mailman/listinfo/plone-framework-team