@serge73 may I ask what's your use case for Plone 5? why do you need to migrate your working Plone 4 site to Plone 5? just because is there?
my own advice: wait until Plone 5.1, at least, as it will include features to make porting add-ons easier, cleaner and faster. after the add-ons are there, you can start thinking on migration, but not before.
these are two important PLIPs in the future of Plone:
If not switch to a new version, then after a while the site can be discarded in the trash.
Old design, slow, no new and modern technologies all of this alienates new visitors.
Can't imagine if I still used the version of Plone 3
I have been using Plone 5 in production for almost a year now with several sites, some very complex. I've migrated many Plone 4 sites to Plone 5. We have found and fixed many bugs in 5.0, and are now (as of the last day or so) on 5.0.4. These are signs of continuing good quality and process, so I don't agree with @hvelarde that people should hold off until 5.1.
The whole resource registry thing is still completely broken and unusable for integrators in Plone 5.0.
That's why we can only recommend to use Plone 5.0 not for fancy projects at this time. Hoping for Plone 5.1.
Stubbing in 5.0.1+ goes a long way toward solving one of the biggest problems. The only 5.1 value-add, AFAICT, from is meta-bundles, only decreasing number of downloads, not really making things different/easier for integrators.
It's not about making things different or easier, it is about making things working, reliably working.
As said earlier:
handling of legacy declarations in cssregistry.xml and jsregistry.xml is not working properly
taking and using a third-party Javascript add-on as-is is not working
resource bundle can not deal with multiple JS files which makes it very hard
Every integrator will be find with a different (hopefully better) approach as long as it works as announced.
At least playing with JS add-ons in Plone 5.0.x is like playing russian roulette with 6 bullets in the revolver.
That's why I refuse to spend any further time in one of my Plone add-ons until 5.1 is on the horizon.
Everything else is a waste of time right now with Plone 5.0.
Sorry, a single resource can hold one JS file and arbitrary CSS files. Some add-ons require multiple JS files to be loaded). In such a case you need to use a resource for each JS file and put them into a bundle...this is really over the top.
Oh ok, right, one JS by resource.
Well, I guess it is due to the Mockup logic, where resources are meant to either package an external dependency (like Jquery, Backbone, etc.), or a pattern (where require manages the needed dependencies). So there is no need to allow multiple files.
I agree it would be handy if you just want to package few files. On the other hand, it would be a little confusing: packaging files together is what bundles are meant to do.
The principle is the following:
each single file is a resource (more or less equivalent to a "component"),
resources are packaged into bundles (equivalent to a "module"),
There can only be one JavaScript per resource because of RequireJS. The JavaScript file in the resource definition is the RequireJS module itself. RequireJS needs to take the module, which has a define call in it and return it to the require call, where the dependency is used.
For example lets see this registry.xml entry for the RequireJS dependency mockup-registry:
The prefix, and there the part after plone.resources/ make the RequireJS config dependency name, as you would define it a RequireJS config.js file. If you could define two JavaScript files for one RequireJS resource / dependency name, how should RequireJS handle that?
By the way, there is a distinction between module-resources and bundle-resources. Both are defined the same way in registry.xml, except that bundle resources cannot have a shim config because that would not make sense for them.
Module resources need a define call in them (otherwise they won't be modules) and bundle resources need a require call in them (they are the application's entry points). The require calls (bundle resources) are immediately executed, while define calls (module resources) are executed when they are first needed by a require call. Because those bundle resources are called immediately, you can also define a dependency on another bundle in registry.xml. This defines an order, in which the resources are loaded.
Resource registry bundles need resource-bundles files - you cannot simply add all the bundles module-dependencies as entries to the resources node in a plone.bunlde definition in registry.xml. Even if it would be technically possible (maybe fixing this would be a worth a PLIP). But - I think - you can add multiple bunlde-resources to a plone.bundle definition.
For reference, this is a (simplified) bundle definition:
Developing JavaScript in Mockup is MUCH much better than developing JavaScript in previous versions of Plone. Declared dependencies are really great - they give us much more robustness and deterministic behavior than before. Testing JavaScript is also most of the time much easier than writing integration or functional tests in Plone and mocking half of the stack. And the JavaScript tests they run very fast.
But RequireJS is a kind of a beast. I'm looking forward to the time when we can use ES6 imports. But now we have this stack. Plone's resource registry is built upon RequireJS and the JavaScript Less compiler. The integration of RequireJS in Plone and the whole developer UX is complicated. Understanding RequireJS helps a lot with understanding the resource registry, but still the resource registry uses a lot of new vocabulary and this whole thing is confusing.
I don't wont to do JavaScript development like we did in Plone 4! That was only JS hacking, no real development. And we had no tests, except some Robot tests, which indirectly also tested JavaScript.
The current approach is a big improvement, EXCEPT that many things got more complicated.
Maybe we can solve the developer UX issues via some different information design.
Recently I refactored and fixed the filesystem based development scenario a lot (in coredev 5.1). As you may know we have a script ./bin/plone-compile-resources It has three jobs:
read Plone registry, create a gruntfile and turn ++whatever++ paths into filesystem path (and copy files in a tempfolder if located in ZODB).
create a package.json and run npm install
run grunt compile-BUNDLE (or all, not recommended).
A major problem are dependencies between packages. Usually I'd expect a bundle to declare its js resources used automatic or explicit to be consumed later by its dependencies. Currently this is not the case. To not get all used already loaded/compiled JS from dependent bundle again, all resources must be declared as stub resources in the custom bundle. This is crazy and an logical indirection .
Overall I think the current approach dealing with JS in Plone is way too complex. I agree with Johannes overall, and given the TTW focus of JS dev in Plone it is probably a difficult task, anyway: for some addon dev our resource registry is too much.
even as I am a big supporter of the concept of planned obsolescence in software (and only in software), it has to be, by definition, planned.
if you're planning to upgrade software to a new version that includes huge changes (some of them backwards incompatible), some new features that hasn't been tested enough and some very obvious bugs, then you're making a big mistake and you're going to pay for it, and it's going to be painful and expensive.
good luck on that, I'm out.
it's simply not true that an old site will need to be discarded to trash if not updated; as with everything in life, it depends: we still host some 10-year-old Plone 2.5 sites for customers who have no money to pay an upgrade, and they are running on cheap $5 USD cloud servers, and they are fast enough to serve their visitors.
can we stop denying the obvious? Plone 5 has/had some very nasty bugs that make impossible to easily migrate sites from previous versions, the last of them was this one which was fixed by @ebrehault last week and only will be available in Plone 5.0.5:
if you have been successful, maybe is just because you work with the smartest guys out there (the ones that made those changes for Plone 5 and the ones who really understand the whole thing)… and/or, probably, because you're still using Archetypes.
for normal mortals with average 10-year old Plone experience, like me, that's simply not true.
and yes, I'm still waiting for Plone 5.1, but I'll give a try to Plone 5.0.5 also.
