@jensens Could we not tweak the existing mosaic to improve the last few UX bugs instead?
I get that it seems like a good idea to reimplment in something nice and new and clean but:
a) I've seen the existing jquery code. It's not that bad.
b) The choice is React or angular2 or Vue or whatever will come next. It's not an obvious choice. Including something new to Plones core means committing us to maintain it for a very long time. It should be a considered decision and only done when there is a clear and obvious choice IMO.
c) Good angular2 and react developers are like hens teeth to find. So the argument that it will be easier than finding someone who wants to modify jquery doesn't really hold.
d) Plone needs mosaic in the core now to be competitive. A project to reimplement is likely to get halfway and then take a long time to finish the last 20% of features which are already in the existing implementation. This will put us in limbo for 2 years I'd estimate. esp if done as GSOC instead of a fully funded project.
At least start with some good reasons why to reimplement?
The need of rewriting depends on the requirements. The main reason, which I could think with the current editor requirements, is to enforce some current architecture around the code base. The current is completely custom (while embracing jQuery practices). It's not bad, but it's still hard to find where and how things happen, and it not obvious, how you extend the editor with custom features. Also, it does have a good amount of dead code / unused features – all hard to detect or understand unless you know the history. Finally, modern frameworks offer modern development tools, like "hot module replacement" with webpack (code reload without browser refresh).
I think, Rob's rewrite attempt https://github.com/robgietema/mosaic is an example, how this could look like. It's also an example, how it might still look alien for any non-react-developer (and how the development tools are probably already outdated and unable to build it).
Ramon's attempt https://github.com/bloodbare/ng2-mosaic is completely different. It assumes completely browser rendered plone-client-like UI with plone.restapi, JSON serialized schemas and possible plone.restapi support in Mosaic backend.
Some limitations / restrictions to consider:
We might need to keep the editor using HTML form based API. Mosaic Editor relies on z3c.form based form views from plone.app.tiles. Nathan complained that a lot, but replacing them with JS rendered forms is not trivial (I recall that plone-client managed to do that with plone.restapi, JSON serialized schemas and ng2 form library[?]).
We should not simplify the current Mosaic Editor configuration until we know the features we want (editor configuration is very verbose and has seemly unnecessary fields, but initially it did have use cases for those). Should we make the configuration editor a GSOC target instead?
TinyMCE will remain hard. We cannot replace TinyMCE with e.g. ProseMirror if Plone core does not do that first. And with Mosaic, TinyMCE breaks every time there is a close DOM change, and the code is full of re-initialization of possibly dead editor instances.
(if this gets too long I'll split the thread away)
I am really not from the rewrite-everything-party. But well, in some cases it is the way to go. It is also IMO a blocker to get the whole into core: p.[a.]tiles, p.a.blocks are in a good state. p.a.standardtiles needs lots of love (i.e. overlaps with p.a.layout, get rid of viewlet wrapping). But mosaic itself is very opinionated, esp when it comes to the editor.
Reasons to replace the current editor:
nearly impossible to maintain its Js code - too many LOC,
too many special cases bloating the code
with jQuery only the code bloats - modern frameworks would reduce it (helps focus on the problem to solve)
enhancing/ customizing JS wise is nearly impossible w/o forking
no overloading of the edit form: independent editor. Still have normal edit form if needed.
development mostly independent from the backend (maybe except forms, which can be loaded async if needed)
to have tests
Missing features/ needed enhancements:
simplify the configuration.
integration in the toolbar - having two toolbar is hard to explain to most of my customers
multi-panel support
better grid system support (no additional wrapping possible, nested grids not possible, I like the Wordpress way here, but combined with our WYSIWIG approach). Use the columns of the original grid system and configure how to divide them.
native grid system class support (do not wrap 'em - this leads to confusion, even if configuration is simpler with BS4)
per-layout base grid support, but have some degree of freedom inside this predefined grid
(would find more, enough here)
Anyway, in my opinion, a defined process where first the requirements are defined and then get implemented is easier than fighting - and breaking - the current working code. In fact, we know what we want, we know what we have and starting a well-defined process from there as a rewrite is probably the easier approach.
All good points but doesn't counter the original concerns raised. Picking Angular, React or Vue I'd say we have a less than 33% chance of having a technology in our stack in 4 years time that is popular. Also what is the chance of us having something that can go into the core at the end of GSOC and what is the plan B if that doesn't happen?
Very good point, that's the javascript world - far away from stable (and light years away from mature), a state we aim at with Plone. Anyway I doubt it's better to stay in JS Iron-Age (jQuery).
I've got to agree with the last 2 statements too - the choice to leave it as is also a technology choice that probably won't be popular. I think you've got to encourage exploratory programming here (perhaps preceded by creating a "headless" mosaic branch (if that makes sense).
Maintainability is a major issue - but so is catching up with other offerings out there.
I discovered a(nother) JS framework called Durandal yesterday that claims
"We didn't try to re-invent the wheel. Durandal is built on libs you know and love like jQuery, Knockout and RequireJS."
which is interesting given the Plone has already got JQuery and RequireJS solidly in mainstream.
One thing I would say was important is better responsive grids - where tile rows can optionally wrap around on smaller devices, and tile width is decided (and stored) within the tile, not in the layout. That may conflict with what Jens said, I don't know all the factors - but just wanted to raise it.
With wrapping, I did mean the CSS class wrapping we do at the moment. It's way better than the crazy in code wrapping we had before but is limited to 4 columns and all is hard coded in the JS.
imho the limitation to four columns is really an issue, as well as the missing possibility to create subcolumns https://github.com/plone/plone.app.mosaic/issues/240.
furthermore the way css classes are generated also isn't very handy https://github.com/plone/plone.app.mosaic/issues/120.
As I've been told, these issue can only be solved in a rewrite.
I'd very welcome a more flexible layout editor, no matter what js framework is used.
@djowett the author of Durandal has also founded the Aurelia framework, after he left the Angular2 Group at Google. It is really nice, a lot cleaner and very popular meanwhile too. But i thing any of the more modern options are better then jQuery and more important better then a lot of outdated unused code nobody of us is familiar with.
We should discuss the different approaches, also @ramon ideas but focusing on the current (not-headless) Version of Plone. So we can have this in Plone soon.
So after knowing what target we want to achieve, I'm for building a new version.
But probably better not in GSO this time.
Ah - my mistake I saw the video of that & assumed it was a codename for Durandal v2. Interesting he felt enough improvements were needed on Angular2 to justify a new framework. [or maybe he just felt there weren't enough JS frameworks ]
(above emphasis mine)
A limitation to 4 fixed size columns is a big issue in my book. It doesn't look like a modern grid system. If that can only be solved with a rewrite, then (sorry to say) IMO I think it very unwise to merge Mosaic into Plone core until that is solved. As I see it we would be walking ourselves into a dead end - with a hard migration story out of it.
This is not completely true. The editor was designed at time, when 16 column grid was popular. Instead of exposing every column, it was configured to expose opinionated set of widths ("quarter", "third", "half", "two-thirds", "three-quarters", "full"). But it is true, that the default configuration can really be changed only by forking.
For content layout the 4-col grid is enough, but i thing you guys talking about using it for site layout, right? And the grid is now easy to customize with your own css/less. It's true that it could be more flexible in the numbers of columns it supports but we can change that in the future. That shouldn't be so hard, to make this configurable even with the existing code.
I don't see Mosaic for site layout in core for the first step, but for content layout it brings us a lot. @djowett of course it has to be ready before it will go into the core
Ok, I'm maybe not understanding the possibilities / limitations quite right. (I never understood why the world at large felt 16 columns was better than 12).
Can users easily get the following in Mosaic?
| xx | xxxx |
| xxxx | xx |
Or this?
| xxxxxxxxx |
| xx | xx | xx |
| xxxx | xxxx |
I'm kind of comparing to the Google Sites editor shown High Expectations of Site Authoring and Page Layout. I wonder if the storage mechanism, the layout tool and the tile configuration tool can be (or are?) 3 distinct parts, and therefore the layout tool can be switched for circumstances where the editing user has different requirements or priviledges, without throwing away the other bits.
(Right, I think I should shut up & let other people have a say)
@djowett your layout examples are possible, problems arise if you want to achieve any sort of side column (without the portlet column). This is not possible without creating a special layout, which is not doable for a normal user.
I doubt that a user who is evaluating Plone and Mosaic will understand or accept this limitation when comparing with other site layout solutions.
Thanks! That's the sort of thing that could help IMO - not sure blocks flying to the top of a column is quite expected behaviour in our case, but there's another 486 forks to check
]