so why are you posting it in a thread about the future of mosaic? No one is stopping you creating yet another plugin that muddies the water and doesn't progress collective improvement of plone as a CMS.
Forking things and reinventing things rather than putting in more effort to come up with a general solution for/with everyone is what is wrong with Plone today. /end rant.
<rant>
And why we don't put any effort into Mosaic? Because the complete Mosaic project is a major failure since the earliest times of Deco and related experiments. Mosaic is still in an unusable state, full of bugs, full of flaws..shall we wait for some more years for getting something mature?..Mosaic has failed. </rant>
Creating yet another layout system that only solves half the use cases doesn't solve that problem.
The bugs are in editor component not the architecture. Replacing the editor only with a better code base is one way to solve that if it can be done in a way doesn't overly disrupt everyone using mosaic right now.
What should I say, it would really a nice thing to have support for CSS3 grids. I need this in a bunch of Projects. I don't know is it alright to override/delete/replace the default css class definitions/rules with grid definitions.
Perhaps yet another solution that works for us and our usecases..perhaps a solution that is accepted by users...perhaps a solution that is based on modern technology and architecture..perhaps a solution that will work within some months of work...compared to what? See above...I demoed Mosaic yesterday to a customer...results: thumbs-down...I
I recall I told Sam not to hurry with that. i believe Nathan managed to get everything into a pretty stable state for Castle. The big changes in plone.app.blocks were to move serializeble (no blobs) tile configuration from separate annotation objects to a layout like field (to make the data behave better, allow custom storages and allow some neat things in the future). Very backendish stuff. And to be honest, I'm not sure how much appliable patches Castle still has in its editor. Nathan did good work in backporting stuff and probably backported most at Mephisto sprint in 2016...
Simply mapping current Mosaic grid classes to CSS3 grid only makes sense if your theme elsewhere already uses CSS3 grids and you need to be comply with that. That's because the current Mosaic Editor creates HTML markup with a lot of wrapper divs for everything to make it work with every legacy grid system before CSS3 grids. Getting rid of those and embrace CSS3 grids would simplify editor a lot and also make "page layouts" editable by hand, because all that special Mosaic markup would no longer be required
About your grid editor implelentation: Do you manage with flat markup (just the grid node with tile children) or do you still need wrapper divs for something? Do you use inline styles for setting CSS grid rules or do you map those with CSS classes, or something else?
A Mosaic version implemented in VueJS, Aurelia or React, which uses tiles and blocks, would be the best way in my opinion, if someone has the budget. Reimplementing the whole thing does not make much sense to me.
CSS-Grid and Flexbox support sounds good indeed. But this is not a blocker to the current implementation.
It will take a while until every one is moving to CSS-Grid. You need new browsers or you have only the basic mobile version. Which should be fine for many projects but not for all.
I would like to collect tasks we want to solve to make the current implementation better.
If we replace the UI later or sooner with something, does not metter for that.
We need a Roadmap with things to improve soon and in the long run. Many of them are not much depended on the editor it self, but on the layout editor and layout template management.
Rob made the classic Mosaic editor work in plone-react. We have a basic MVP of the new Pastanaga editor in place in our project (based on draftjs).
Anybody can start from the scratch if they want. Writing an editor from the scratch is not trivial though and we did a lot of research on that front in the last year.
I'd recommend collaborating on what we already have...otherwise you will end up solving the same trivial problems over and over again without even touching the complex use cases.
Plone is NOT a CMS - it's a Website Publishing Platform.
Ok, that's rude. I'm sorry. But here's an idea. Let's stop using the term CMS to define Plone, which everyone has some kind of definition for, and therefore can have a semantic argument. But invent some new term that describes what Plone actually is - not what people want to call it.
I'm curious why you don't think Plone is a CMS or why it needs a new title.
One defintion of a CMS is: "A content management system (CMS) is a software application or set of related programs that are used to create and manage digital content."
@tisto I completely understand not reinventing the wheel. I also take your early point about reacts ability to retain server-side rendering. (BTW I personally don't care react vs vue vs angular. Only that whatever we pick has a high likelihood of code debt so better to wait but thats not always possible)
However I'm aware of Plone's history with such big bang changes.
So what do we have to swallow to use this when it's stable? ie
what version of plone will it work with?
What parts of the UI will change and what will be incompatible?
Will it require plugin upgrades?
Will themes have to change?
What is the likelihood that every action you can do now with the Plone UI will still be supported or will there be a longer period of reimplementing everything in the UI?
If Pastanaga is a very backwards compatible release then that seems like a good way to go. Even better if just the the Layout editor component can be separated so it can be retrofitted with 5.x sites using mosaic?
Pastanaga demo site ? could such a beast exist today ? I have looked it up on github and pastanaga seems to be a specification for a future Plone UI, not a software. 2 implementations of this spec are in development, one using react (plone-react) that seems to be led by @tisto, and one using angular (pastanage-angular) that seems to be led by @ebrehault.
AFAICT neither is ready to be demoed. How the best will be picked is unclear. As for compatibility with existing features like add-ons and themes it's not clear from the spec either. My personal guess is that's because it's to early to tell.
) would be as useful for a lot of users as something new ?