I agree that supermodel XML would work with decent work (with the current Plone stack). With the current Mosaic it would be wizard like: select "Theme tile/fragment" from tiles menu, select tile/fragment, fill schema based form. (Mosaic tile configuration should be enhanced to better support these kind of use cases at some point...)
@espenmn You asked, why folder full seems broken with Mosaic. It is because installing Mosaic (alpha) changes Document default view to "view" instead of the default "document_view". "view" is a Mosaic layout and Mosaic layouts are not currently supported with folder full view. (Once I changed Document default view back to "document_view", folder full view worked for me.) Maybe that's a reason to make Mosaic default install not change default views for existing types (and maybe add another profile for doing that).
A progress update, while we are getting closer to Mosaic 1.0b1.
The first beta will take a few steps back and focus on content area layouts. Site layouts (main_template replacement) will be hidden behind a zcml feature flag.
TL;DR; Mosaic 1.0b1 will cover two to three use cases:
-
TTW type views: predefined centrally managed tile based layouts can be assigned to content types and selected by user through Mosaic Editor (similarly to selecting legacy views through display menu); these centrally managed layouts mostly "static", but users may re-configure tiles in them per content when necessary
-
inline editing: Mosaic Editor provides inline editing for most text based fields (and more should be implemented later)
-
free content area layouts (by selecting a predefined centrally managed layout and customizing it – obviously making it no longer "centrally manageable")
(In addition, it should be possible to introduce "Mosaic customizable areas" outside the default content area by introducing new "panels" through portlets or viewlets, but I'm yet to document this feature.)
Flow described:
Once user installs Mosaic add-on, there are no other visible changes than a new "Mosaic layout" view option added for existing content types. (New content types with Layout behavior would have it for default with no other display view options.)
Once user selects "Mosaic layout", a registry configured default layout is used (or error layout is shown when no layout is configured). This layout is centrally managed "static" layout.
Once user clicks edit on content with "Mosaic layout" activated for the first time (or adds a new content with Mosaic layout as itse default view), a layout picker is shown. Picker will show all available layouts for that content type. These layouts are centrally managed "static" layouts.
Once user has selected layout, Mosaic Editor is shows the content with that layout. User can use Mosaic Editor to update content fields (either via inline editable field tiles or through properties menu). Tiles in layout cannot be moved, deleted or added, but layout may include configurable "app tiles" (like content listing tile, RSS tile or even additional rich text tiles), whose configuration can be customized through the editor, while keeping the overall layout centrally managed.
Optionally, user with proper permissions can select to fully "Customize layout". This will copy the selected layout into the content object (to what was previously called "Custom layout"). Now the layout is fully editable.
Optinally, user can "Change layout", which will show the layout picker again. This will abandon customized layout, but may re-use previously customized tile configurations.
This flow is mostly visualized in:
http://plone-app-mosaic.s3-website-us-east-1.amazonaws.com/artifacts/577/577.2/getting-started.html
Thanks to @vangheem, who did most of the work to make this flow happen
2 Likes
Great work @datakurre and @vangheem, I can't wait to use Mosaic!
Wondering if you already had a thought on how to deal with responsive views hence different bespoke views depending on the screen size or whether the device is touch enabled or not.
I'm then curious to understand how the top horizontal menu would work on mobile small screen sizes but I appreciate it's not a priority at the moment.
Keep up the good work, you're amazing!
Cheers,
Enzo
Thanks. Its really helpful to explain the user story.
A few questions.
So how does it match up a edited tile when the layout changes?
Also if a centrally managed layout is edited how does it handle retaining the tile info?
In the original deco user stories was the idea of inheritance of layouts, in particular site layouts. To replace portlets. Or are site layouts not there yet?
If a tile is edited at the central level is it locked for editing at the instance level?
Mosaic has abstract grid support, which on Plone 5 defaults to generate BS3 compatible markup. So, the resulting grid is somewhat responsive by default. It supports viewport size annotations so that eg. BS3 can hide and show tiles on the fly, but configuration for that is not yet exposed in Mosaic Editor.
The editor does not have touch support yet (although, simply translating touch events to mouse events should not be too difficult to add).
Tiles are matched by their id (also transient tiles may have id, even it makes not much sense outside this usecase). There's still no editor for centrally managed layouts, so currently the use of matching ids is up to the layout designer. (Probably the next step in this is to provide "Share" button into the editor, which would save customized layout into global resource directory.)
Site layouts will be disabled/hidden by default, because we do not seem ready for them yet (there's only automatic main_template generated sitelayout with a single "content" named panel for content [area] layout).
Customizable tile configurations for static centrally managed tile layouts is implemented by transparently applying persistent tile data manager for customized tiles (whether they were implemented as transient or persistent). This means that once tile configuration is customized, its data is saved into and read from persistent annotation on the current content object. (There will be automatic [ObjectModifiedEvent triggered] garbage collection later.)
Tiles in centrally managed content layouts can be annotated "readonly" so that their configuration cannot be customized.
AFAIK on the fly merge of inherited site layout to make it possible to replace portlets was only idea, but never saw even a proof-of-concept implementation in Deco stack. It's still an unsolved problem (how to implement it without significant performance issues). Yet, because we do not seem ready yet to leave the main_template behind, there's still plenty of time to think about this.
1 Like
Bootstrap 3 is probably a good standard. Plus one grid (such as BS3) can be transformed to a user's preferred grid system with a some Diazo rules.
I Really Love Plone thanks for the new layout
1 Like