The resource registry has lots of potentials for improvement and documentation. But it's not so broken as you always mention @hvelarde. In fact, it works surprisingly well, given the complexity it has built in (TTW compilation). In the end it's just a registry which spits out some static resources. The improvement would mostly be a simplification than anything else and an abandonment of the TTW compilation support since we do not really need TTW compilation anyways (registering pre-compiled bundles and concatenating them would be a sufficient replacement for people who do not know JavaScript build toolchains). More on that: https://github.com/plone/Products.CMFPlone/issues/1955
at the end, this is pretty funny: you finally arrived to the same conclusions I did one year ago in PLIP 1896.
one year! it was hard to recognize the obvious, right?
I'm not going to use any new version of Plone until I can include my static resources in a sane way; and I'll keep ranting about it until the framework team takes this challenge seriously and start a discussion about ways to fix it.
BTW, have you seen this or I'll have to wait until 2019? a sane way to handle static resources for add-ons! check it, use it, learn about it, criticize it... but don't keep just looking at your bellies: there is a whole world out there with different ideas on how things could be done.
do you guys want to talk about this on the next framework team meeting?
Well, @hvelarde, first, for your specific project, it is easy to just use webpack, configure your stuff as merger into the RR, done, if thats what you want, it does not need any RR specific compiling, just merging as @thet said.
Seconds if you use just Plone 5 it is - as @thet said - not that bad, except you try to do TTW compiling. Don’t do it. The old-but-working grunt scripts are working. I used them, I fixed tem and if you use them as they are supposed to be used it works. Sure,if you want to do it /your/ way: dont expect it to work. Meanwhile in a recent 5.1 all is OK, even if its no pretty.
Third, yes, there is your PLIP, its complex, topic is difficult, and there are so many ways around and also tools. You closed it with "I'm closing this as seems to me there is no interest on addressing this issue." Which is wrong. The FWT discussed it in depth and collected some good arguments that it may need improvement. You didn’t liked it, ok, its your decision to close it instead of improvement to find a consensus.
Also, I would kindly ask you to cool down a bit in this discussion. Some of your points are valid, but they do not need this aggressive tone. Thank you.
you're right and I apologize: the problem is nobody answers when I use the "right" tone: I've tried asking many times in the past, I've made proposals, I sent direct emails and the topic is just ignored.
and now that I think, this is probably ignored because you guys feel comfortable the way it is and that's not going to change because you are busy with other stuff, and that's a valid point; probably I just needed someone saying that clearly.
I am completely on the side of @hvelarde and sharing his pain with the situation. The resource registry is completely broken - from design to implementation. And there is no way how to fix them. This thing is completely kaput. You are just adding some more layers of ducttape...BUT...there is a way to live without them and a way to ignore them - at least for 99% of our own usecases and project requirements. Life is good again after ignoring resource registries completely in Plone 4 and 5.
@hvelarde : please list your current problems with the resource registry in the issue tracker. @zopyx has submitted many issues - I'll later check them if they are still valid.
I forgot to mention that many things have improved in Plone 5.1, which is not released yet. Also documentation including solutions to common use cases is missing. But otherwise, I don't see many problems with the resource registry when it's purpose is to include JS and CSS resources in the output.
It's true the Registry was not much stable i nthe first place.
But some people did work on it and it's better now.
If you use your own resources/bundles for your addon, there shouldn't be a problem.
With the later added merge option, which BTW works like the merging in the old registry, you can merge your resources into one of the two default bundles Plone comes with. The TTW story still feels not stable and proably never will be. The only except i would make here is, the less compiling TTW. I like this to stay.
But for the rest, we could reduce step by step the complexity as @thet suggested. Bundles are not really needed for your addon. But this is not the big pain point.
What i would like to have changed, is the varibles for the CSS/LESS.
This still seems not working well or at least is confusing for many people.
So either not support it at all or fix it by providing a simple server side rendert LESS file, which provides the needed LESS variables. So that everyone can change some colors of the default theme of plone. @tmassman did some interesting work too for this kind of persons with his customizeable theme.
All the javascript stuff should be bundled and compiled outside of Plone, with some tool like Webbpack or what so ever. For addons one can use what ever she wants and in core we define a standard but without this tide integration and the requirement of starting a Plone instance to compile the resources.
@hvelarde it is good to point out problems, but please keep in mind, we all have limit time and different needs and therefor different priorities. If someone like @thet steps in and spends a lot of his time to improve the current situation for all of us, it's not nice to rant like this. Many of your points are valid and many of us thing the same. But someone has to do the work. And this is the kind of work, where you get no direct project money for. And some of your points in the plip are already possible. For the rest lets open issues and fix them. I don't see a team somewhere who is defining a complete new solution for that, we have to evolve here the current one step by step.
It is a bad sign if a senior software developer (me) is not capable to include an arbitrary JS lib into Plone within some hours.
I am no JS specialist. A person with more JS background may have found a way. But as it is Plone repels the user base if "JS integration" is so hard.
Problems are not solved by ranting or making proposals. Only hard work can achieve this. I therefore volunteer for documentation and samples for integration of 3rd party JS in Plone.
My company has some plone packages from customer projects featuring the integration of
bokeh
datatables, jeditable
cytoscape (not working)
that we can bring to GH as example implementations and for use in the plone community.
Exact same situation here. My rants about thr RR are well documented, RR are atill broken in 5.1.0 since I link
and a related issue where you can easily mess up the during site creation using addPloneSite(). RR are still fragile if you dont them yourself.
My way around RR issues?
Do not use them all. All of my Plone 5 compatible code includes the JS and CSS of thirdparty modules directly inside the templates..completely old style..the code remains compatible with Plone 4 and 5. This is just working..no more wasting lifetime with RR. And no more wasting customer money and project buffers with RR.
Here is an example how my third-party JS integrations usually look like.
Completely old-style, exactly the way how you would do it in Plone 5 but robust as hell, easy to maintain and just working. I have been using this lately for various DataTables integrations, agGrid, Leaflet.JS and various others.
As Datetables.net integration can load something like 5 JS and 5 CSS files...but who cares? Most of our DT-driven applications load code and data in max 2 seconds. At some point all code is in the cache and nobody care any more about network activity. A pragmatic approach that works, that is predictable, that saves money and frustration.
