I'd like to announce an open space about Plone Mosaic at Plone Conf 2014.
Plone Mosaic sprint in Barcelona revived the Deco vision of modern page composition for Plone: new responsive site layouts, new drag & drop content type views, etc. During and after the sprint we managed to integrate almost everything in Deco to work incrementally and nicely with Plone 4.3+ and your existing content. Also a configurable grid system support was added.
Basically the backend works, but front-end would need a lot of work, and some of the work done at the sprint being already outdated for Plone 5 because of deprecation of plone.app.widgets and the new resource registries in Plone 5.
Plone Mosaic is still quite disruptive tech for Plone. Tile based composition allows to split page rendering in separate, smaller request, cached separately using front-end caching like Varnish (yet non-ESI-rendering in a single request does still have performance issues). Also, like in the Deco vision, Mosaic supports per section (or per page) site layouts, and its composition possibilities also overlap with Diazo.
Before the conference, please, ask questions about Plone Mosaic here.
I'd like to single out a particular new feature in plone.app.blocks into discussion: tile-specific Diazo-transformations. Meaning that a separate Diazo transform can be applied for each tile inclusion.
The good:
because diazo rules are only applied for a small content block, they stay simple
site layouts can bundle themes without plone.app.theming (which limits to one active theme at time)
The bad:
multiple Diazo transformations for a single page might be a performance nightmare (while transformations themselves could be faster, because of simpler rule files)
The controversial:
competes with plone.app.theming
Example (look for data-rules-attributes):
This feature is presented also in the Mosaic site-layout screen cast:
I guess it doesn't like threaded replies. Let me try again.
Does this mean that different plugins could install diazo rules for the same kind of tiles which would complete with each other + compete with the theme?
One thing I really like about plone.app.theming is that it gets rid of this notion of plugins providing style and JS etc. Because almost always, a plugin authors opinion will conflict with theme and it makes the job of the theme creater very hard because they then have to consider every possible plugin that might be installed and how that would change the html and js or css. Plugins like truegallery and collective.carousel we just don't use anymore because of these reasons.
I think a much more sane system is to encourage tile and plugin authors to provide very basic html and interactivity and rely on a themer to integrate it into the theme if something different is needed. Perhaps a plugin could suggest diazo rules the themer could apply to get different designs but I don't think they should try to do anything fancy.
No. Tiles should always provide only basic HTML. Plugins may provide example layouts, but I consider layouts as something, you always customize for your deployment.
But my opinion is that layouts do conflict with theming. Yes, you could try to provide generic layouts bundled with plugins and then let integrators do their customization in diazo. But customizing layouts is easy, and if you need to touch the layouts, you soon find yourself doing theming twice: once for layout and then another time in plone.app.theming.
(Another issue is that, AFAIK, there's no way to do any kind of Diazo for ESI tiles yet.)
I agree that the conflict between layouts and theme is hard to solve. With layouts we give the power to editors or site admins and it makes themers job harder since they have to consider all possible layouts in advanced.
Without layouts we give the power to the themer and he/she can then hard code the layouts in advance making the theming process easier therefore cheaper, but then editors/admin have to go back to the themer to ask them to modify it if their needs change.
Basically it's a Plone vs Wordpress style of theming. I don't think we can really have it both ways.
But, still, Deco and Diazo were both included the original three Ds. Yet, now it feels that Diazo-users are perfectly happy with the default Dexterity views (easy to theme with Diazo) and when I'm using Mosaic, I'd like to do the theme completely with layouts.
Well, we did have a small open space and sprint for Mosaic at Bristol.
At the open space we mainly discussed about, what should be in the first release and concluded that we really should go for the minimum working product possible and continue thereafter.
So, the first Mosaic version should only contain "the custom layout" feature and a button to save and load layouts when in editor. Technically, we would not remove features, but just hide the layout fieldset from the edit form.
The second release would have UI for saving layouts as named views for dexterity content types.
Finally, if there's enough movement to create a site layout editor, that would be only then. The site layouts are the most controversial feature, because even they are main point in tiles based layouts, they compete with p.a.theming and diazo.
What comes to tiles, before the first release, we should go through the available tiles and disable all that don't work and only add them back when they are fixed. (Tiles are enabled/disabled in p.a.registry, but there's no UI for that yet.)
After the open space Rob (the original author of the Deco editor) sprinted on Mosaic editor and fixed most (if not all) known bugs in the basic layout editing and Ramon made sure that everything works on Plone 5.
Personally, I still want Mosaic to also work on Plone 4, but it took a while for me to catch with the current JavaScript workflows to able to build the fixed JS also as a bundle for Plone 4. Now I'm waiting for a new p.a.widgets release to get rid of a few widgets' related issue, and then I should be able to merge the newst JS also for Plone 4 into the p.a.mosaic master (and also update the heroku demo deployment).
I'm also coming to PLOG, and I should be able to give a quick update on Mosaic, but will otherwise focus on having a holiday instead of sprinting.
This is a great feature.
Are there any docs on how I can make a diazo theme available for mosaic ?
Let say a develop a new theme for Plone 5. What would it take to also make this available for diazo.
@espenmn Which feature, in particular, are you referring to with "make this available for diazo"?
Diazo and Mosaic are different features. They should complement each other so that, once Mosaic takes layout configuration and grid management into content space (like front page should have X columns and Y rows and content in this section should have Z columns and single row), diazo theme itself could be simpler. Historically, we used to talk about "three Ds": Dexterity, Deco and Diazo. Mosaic replaces Deco in that list.
Yet, Mosaic is currently missing configuration panel. It is an possible option to somehow integrate it with theming control panel, maybe even make it configurable with uploadable theme.
(Technically, Mosaic is currently configured with registry configuration and html resources [uploaded similarly to diazo themes, but just missing UI for it]. So, Mosaic configuration uses the same technologies as Diazo theme configuration, but are separate from Diazo theme configuration. I'd like to keep them separate, but it would still be nice to be able to embed configuration with theme. Maybe the easiest way for this would be to provide plugin for plone.app.theming in plone.app.mosaic.)
We don't know yet, what would be the best way to combine Mosaic and Diazo. Most probably they should remain separate: Mosaic should focus on re-usable context configurable layouts, diazo theme provide customer specific CSS and tweaks.
All layouts currently shipped with Mosaic should be considered as examples and demos (there are also TTW examples in ZMI under ./portal_resources). Yet, control panel for everything is missing, available as an issue for any sprint to pick up.
Let's take the included bootstrap layouts as an example (they are available in the filesystem product, but it is also possible to copy paste them into ZMI portal_resources to make them TTW layouts):
The example BS3 layouts include two different layouts (one clean and one with hero), for example, for editor to use hero layout on section front pages and clean layout on normal pages.
The layouts also configure Plone to transform Mosaic editor grids into responsive BS3 grids.
The final look (CSS, logos, etc) should be provided with a Diazo theme. Yet, because Mosaic already results BS3 markup, the required Diazo theme should be much simpler.
That said, I added some Diazo into Mosaic to make it possible to transform things like global navigation tabs and navigation trees into required syntax directly in layout. That's why BS3 layouts results so BS3 look even without Diazo *). It makes a nice demo, but may harm performance when compared to everything being in Diazo theme. This needs benchmarking.