We have a use case where the administrator can choose a particular content layout for a section (which is a folder).
A content layout for a section/folder is basically the option to choose between a banner, a slider or a video that should be shown above the content body of pages within the same folder. No problem here with a content layout tied to the Folder content-type.
Individual content pages of a particular usually have a Richtext field for the content and the editor should be
able to optionally add some pre-defined tiles likes ads or a calendar into a slot right of the richtext. Also no problem here.
But how can you configure mosaic or the renderer to render section related tiles (the banner, the slider etc.) together with the page specific layout?
No, I don't think you understand Mosaic.
A mosaic layout can render ' everything ', and different for different user if you need that.
including browserviews, pat-inject, diazo rules, tal:replace structure, even 'normal TAL' could work, you could probably even render the tiles of another content item.
Something like that but meanwhile I came to the conclusion that we don't want to use plone.app.mosaic..still buggy, fragile and not friendly to endusers.
Thats fine however the reason I tried to clarrify is I want to know the answer to this too and you might also in the future and so might someone else who comes across this post.
So the kind of scenario I think you are asking is that on every page/folder/news item in the news section you want a special "latest news items" box for example. But not in other parts of the site. But you also want to include navigation and slider and other elements from your default site layout which the rest of the site has, without having to update those in two places.
The way I think it works is that it doesn't use inheriting tiles and slots like portlets does. Instead you create several layouts. The layouts contain the tiles. So you would go set the layout on all the subcontent and perhaps there is a way have a content inherit it's choice of layout from it's parent?
ie, a mosaic page is a merge between the globally defined layout and the current content, and not merging in stuff from parents (unless a specific tile does that internally). Tiles "live" in the content item or the layout, and don't get reused anywhere else.
@datakurre@tkimnguyen Am I on the right track? Clarity on this would be very useful.
In Castle I would create “site designs” that you could apply to individual content items or to folders or both (like placeful workflow policies). Then you could edit a content item layout with Mosaic and save it so others could use it (per content type). I think that would do it.
This should be the same for mosaic. Just not enabled or exposed in theme or layout editors by default.
Yet, I agree with Andreas about the issues in plone.app.mosaic UI. It's unfortunate that we don't have resources to polish it. We did got a lot of fixes from Nathan when he polished the editor for Castle though
The 'drag stuff' can 'kind of' be fixed with just CSS (adding borders to tiles, rows, columns etc with different colours and min-heights (and placeholders maybe)
Some of it just needs documentation (?) … I just discovered it is possible to drag a tile to 2/3
Could some of this be done with 'tooltip' ?
Are the issues which need to be resolved clearly defined enough to make GSoC projects out of them? We get a lot of interest in GSoC projects. If the problems here can be clearly scoped, I suggest that one or more GSoC project ideas would be a good way to try to get more resources involved
Unfortunately, not well enough. Issues like "save button should not be clickable before all tiles are loaded to avoid data loss / editor should load editable tiles lazily for faster startup" require too much insight into existing code base to be good candidate for a successful GSOC project. Sure the skill of reading legacy code is important skill, but in my opinion GSOC is too short for mastering that.
Rewriting Mosaic toolbar and editor CSS, on the other hand, with a good title, could make a reasonable GSOC topic (the current toolbar CSS is from Plone 4 era bootstrap and other editor CSS is even older). I recall @pigeonflight already suggesting that.
Perhaps true, perhaps not..CastleCMS shares the „problem“ with Quaive that you have to commit to a framework build on top of another huge framework...not specific to Plone but also with other software stack..so in our case I decided that not using not Mosaic is the better approach for me and my customer. My disbelief in Mosaic and my own ideas with webcomponets build on top of vue.js appear more solid and more approachable and much easier to maintain..i do not claim having a Mosaic replacement...just something smallwr that works for us.
I wouldn't say that CastleCMS is a framework on top of another framework... it's Plone+ and a lot of its features will eventually make their way into Plone itself, in one form or another.
It's about choices made it overriding the Plone UI that introduce risks in integrating. Often client requirements involve other choices and Plone is designed to be flexible and we know how to customise it. That reduces the risks of quoting on new requirements. Castle and Quaive make other choices and some of them make it hard to integrate with. Basically Plone is designed to be pluggable. Castle and Quaive are designed to be more like apps. Doesn't mean its impossible to do but increases risks. Even more so when you consider that whatever you customise might break in a future Quaive release if they decide to make different choices again, something you have no say in.
