We are currently building a small Plone 5 site with minimal functionality. One stylesheet and one JS file
are registered with jsregistry.xml and cssregistry.xml. I refuse to go with new-style resource bundles for various open issues.
The designer is running its own Plone instance and needs to work primarily on the CSS files.
The CSS is being edited directly on the console. Change to the CSS should be instantly picked up (as we know it from the typical Plone 2-4 dev cycle) without restarting the instance, without rebuilding something etc.
As documented above using the development mode of the resource registries in Plone 5.0.2 does not work reliabiliy, it does not work in a satisfying and non-frustrating way for non-Plone designers. What can be done here?
I would recommend to put your JS/CSS resources in your Diazo theme, that way they will be automatically bundled for you, and they will be reloaded without restarting the instance.
This mechanism has been specifically built to cover the use case you are describing. There is no point in using the bundling system (I mean: explicitly, by declaring your resources, bundles, and so on) just to theme a Plone site. Diazo already handles that in a very handy way.
This is partly true for the Designer doing the "public" theme.
However in role as integrator I need to add some minor CSS and JS code for the editing UI (which is clearly not part of the public theme and therefore belongs into the policy package) and I am facing the same problem
ok, well in that case, putting your bundle in dev mode is the way to make sure all changes are reloaded without restarting the instance, but that's apparently where you get stuck according the issue you have posted, where the videos are not totally clear to me considering I am French and color-blind but apparently your problem is the "Develop JS" and "Develop CSS" are greyed and disabled even if you are in dev mode, right?
FWIW, I have working webpack example with "hot module replacement" support (refresh without page reload) for all core JS/CSS -resources to meet similar requirements. It adds everything into theme, bypassing resource registries for everything else but thememapper bundle.
(Also, if resource registries feel complex, it could be educating to look into that webpack config to see the current "state of JS art" alternative...)
Without that PLIP and the new registry there would've been no usable TTW/add-on JS/CSS solution in Plone 5. The old registries were nightmare with modern JS, and only proposed solution before that PLIP was to use any recommended CLI JS toolchain and bundle ALL resources with theme.
Since Diazo there has been two solutions for configuring JS/CSS in Plone: a) registries b) theme. I'm not adding anything new. Just updating my toolchain for b) from the current "generate and run Gruntfile using scripts in CMFPlone" to the currently recommended JS/CSS build tools.
@vangheem talking seriously, I really don't know what to do about it; there are so many different/overlapping JS/CSS technologies around that I don't understand what's going on, and I can barely imagine how to fix the JS/CSS story.
you made a choice and pushed on that direction, and that's totally fine; the limitations of that choice are unveiling now; let's see how it evolve with the feedback of users beyond core developers.
my point is about underestimating risks, because obviously they existed from the very beginning; we all have to be open to criticism to not make the same mistakes in the future.
and that interesting, probably the future of the JS/CSS resources is going to be very different of what was planned in PLIP 14261.
I read Ramon didn't want to use Node.js but @thet had a different idea; I don't see anything wrong on using Node.js, in fact we are starting to use it more in add-ons; there are tons of nice features out there that can be simply reused by installing it.
don't get me wrong; it's only that I tend to relate things all the time; sorry, I don't want to bother you; you are one of my favorite persons here and one of the guys who work the hardest for Plone's sake.
I'm sorry for distracting from the original topic. Personally I believe that we need both ways (registry / theme) and I'm pleased to see Andreas putting so much effort in reporting issues so that they can be reproduced and fixed. I do so much worse job in that myself. Also, just looking on how much the CLI tools have changed during the development of Plone 5, the new registries are standing the test of time pretty well.
Many of us have tried to write a lot about the choices that were made. It basically boils down to:
we needed js module loading
much of the Plone community is obsessed with the requirement that everything be able to be done TTW. We've had fights about this for years
requirejs is the most stable, long standing solution that works TTW
You don't have to buy into the TTW support for requirejs module loading. Your addons, products can just have one pre-built js file that you include no problem. https://github.com/collective/wildcard.media builds the js file outside of Plone.
@rodfersou You are welcome to try out the webpack setup. Just be aware that it does not fit for building add-on bundles. It's suitable only for building complete site resources.
I use gulp+webpack+babel; I like this build stack for what it does for me (ES6, building single JS from complex dependencies for a data-viz app used in a Plone 4 integration). However, it is wholly inappropriate for the "pluggable application" ("JBOA": "just a bunch of add-ons") environment. That's why we need either the registry we had (Plone 4) or have (Plone 5).
What we had previously does not play nicely with AMD, which I think forces folks hands by its zero-namespaces-loose-coupling-be-damned ideology. For that matter, AMD is not ideal for JBOA, which begs for loose coupling (that Plone 4 has). But it is (now) what we have.
@datakurre's build-it-in-the-theme solution is interesting for sites that makes sense for. For my unthemed integration of a bunch of add-ons making up an intranet site (that is, I am not really using Diazo now) in the JBOA vein, it does not make sense because I don't want to create a theme just to hold JavaScript from disparate add-ons that provide featues a-la-carte.
The documentation is improving for the resource registry stuff, there are a bunch of things about to land in the docs (e.g. @cewing's recent pull request). There are improvements that ought to make things a bit more sane (IMHO, stubbing things is in Plone 5.0.2, meta-bundles in 5.1; only together does this feel like a sufficient JBOA story, assuming everything is documented with examples).
We likely have another upheaval once all major browsers have supported ES2015/ES6 imports for at least a few years. Until that point, I think we have what we have; it is different than what we had; it is more complex. But it is also more modern and delivers more OOTB.
I sympathize with laments of @zopyx and @hvelarde... I'm trying to keep up with the learning curve on this stuff, and no matter what we do, we are asking mostly-Python developers to develop a magnitude more experience with JS tools (not language or browser environment, just tools) than they had to in Plone 4;maybe there's no avoiding that with modern JS story, sigh.
but apparently your problem is the "Develop JS" and "Develop CSS" are greyed and disabled even if you are in dev mode, right?
