This time we are adding a new event, which has a Mosaic Layout as its default view. That's why see Mosaic's "Custom layout" already on the add form. The editor gets its default value from the configured default layout. Because the default layout already contains most of the fields, most of the even field can be filled in-line in the editor.
Also this time those fields are configured "non-removable" and "non-movable", so even the layout is "customizable", those field must remain in their places (unless user goes into browser developer tools to rewrite the HTML in the editor).
I'm surprised, how well the in-line editing already works, but the fields are still a bit hidden and tab navigation has some issues (mainly that tiles are not properly focused). Generally, I have mixed feelings about it. When it works, it's awesome, but when it's not perfect, it might be an annoyance.
I hope sprinters at Arnhem Sprint could look into it, and evaluate, if it can really be made good enough.
@datakurre while I think deco had a vision and some documentation I think @hvelarde and Lincoln are right that we could do with more use cases than we have. What we have is an idea that may or may not work for a variety of use cases. What hasn't really been done is to collect those use cases, sort them into must have vs nice to have and then flesh our stories for each one of how you would step by step achieve using mosiac as its currently designed.
What your doing right now is exactly that, but with a working version and showing the results in videos, which is great.
Now I think we just need to go back a step and work out what all the use cases are.
So
multirow landing page with different styles per row. Different permissions to edit each row. (atlassian homepage)
user creates event with certain field locations fixed but rest flexible. default layout created by siteadmin using layout editor.
??
??
To me I don't see why mosiic can't be designed to do everything that c.cover tries to do.
Just as a note that we could already have per row permissions by using an "external content" tile per row, and maybe editing linked external content could be made easier. That would be mich simpler that implementing permission support into editor, but would result in dummy content outside landing pages.
@hvelarde Mosaic, like Deco, has three different tile types: text tiles, field tiles and app tiles.
Text tiles are not really tiles in p.tiles sense, but are just HTML saved into layout field (next to other fields). Field tiles are all instances of field tile from plone.app.standardtiles. All the other tiles are app tiles.
Field tiles just show and save data into content instance fields, and are indexed by normal field indexing (if fields are configured to be indexed). App tiles are not indexed. Text tiles are indexed by indexing the layout field into SearchableText index (p.a.blocks 2.1.0 will automatically index layout field if c.dexteritytextindexer is installed and the content type has c.dexteritytextindexer behavior enabled).
Did a short demo this week at the Zurich Plone Meetup and fellow Plonistas were quite impressed!
What we really have to figure out, is what functionality should be exposed for which usecase and where - ui-wise.
That said, thanks again and looking forward to the Anniversary-Sprint!
@agitator That's great news. Please, discuss about those during Arnhem sprint. But whatever you decide, please, try to find a minimal route for production.
Mosaic is already technically good enough for me, but I'd prefer to make it suite also for others at the community (and maybe later included into core distribution) to share the maintenance effort. If we manage to "break it" because of too ambitious incomplete refactoring (this was the issue, which prevented Deco from ever getting ready), I may have to fork the last working version for myself, and that would be a pity.
Rich text formatting actions have been moved into tile specific inline toolbars (and/or context menus), which are configurable per each tile in Mosaic registry configuration
Rich text areas are now using TinyMCE pattern, which provides, for example, the usual Plone link action for full featured rich text fields
Close icon (way to remove tiles) has been removed and replaced with Remove button in top toolbar. This makes it more difficult to remove tiles by accident. Hovering mouse over Remove button should highlight the tile to be removed.
collective.themefragments (master, not released yet, README to be updated...) provides a way for creating template (ZPT) based tiles TTW within theme package (it adds single tile, which can be configured to render selected theme fragment from theme)
Nathan has added a control panel for editing alternative content layouts in HTML and is working on layout editor support for rebasing the currently customized content layout on top of another content layout template in fly
Yes, it should be possible to make c.themefragments' tiles support custom CSS, but it would require fragments to be complete HTML documents with head and body and c.themefragemnts' tile to support that. Mosaic / Blocks should have support for merging tile heads into result document head.
About configuring c.themefragments' tiles. It's not trivial, because they don't have schema. Yet, themfragment tile could take optional querystring as an argument and pass that for the fragment tile to use. Some nice widget for building that querystring would be nice, though.
@datakurre
I think having a way to create tiles via a schema TTW would be very useful regardless of themefragments. Perhaps themefragments its an advanced feature.
For example:
fred wants to be able to embed flash files in the site so asks the themer fran to help
fran goes to tile type manager and creates a new tile type with a file field flash_file and a title field and a field for the alternate html if flash is unsupported. (basically the same as the dexterity schema editor)
fred can now get a create the flash tile but it just presents the field data as basic html
fran goes to the theme editor and creates a rule which maps the class for this kind of tile into html for embedding the flash.
fran can export the new theme with the tile definition out of the site and install it on another one. The schemas are saved as editable files, like json or xml.
if fran knew zpt and wanted to call some plone apis then she might choose to assign a fragment to a tiletype. maybe via a diazo rule.
It would also be useful for themeing to be able to create instances of tiles and include them in a theme. For example, lets say you want a special kind of navigation in your header. Instead of using zpt fragments and having to learn that, you could add a folder listing tile to your theme, configure it list the contents of the current folder and then include the tile instance via a diazo href rule in your header. And then use a content to content diazo rule style it like the menu you want.
So
plugins can provide tiles that can be used in themes,
and themes can provide tiles types that can be used during editing.
