Persistent tiles, annotations and attributes

[rristow]

Some points be discused hier:

• How to show the diffs of two different fields data on a single history view (See #345).
• Transient vs. persistent tiles
• Mosaic - layout vs. content editor.

[hvelarde]

Mosaic is a layout editor; managing content and trying to track tiles for content change is the wrong approach to it, IMO.

CC @tkimnguyen

[datakurre]

@hvelarde What's your suggestion?

TL; DR; With Mosaic 2.0 an alternative for diffing rendering output would be comparing contents of content-attribute (includes configuration and content of all tiles except tiles using annotation storage).

Tiles have never been only about layout configuration; they have always contained some amount of content. The first iteration of Mosaic was still quite simple when all HTML tile data was stored within layout in "content" attribute. With real use cases and managed layouts it got more complex.

To re-cap:

1. At first we inherited the original Deco design of transient tiles, persistent tiles, site layouts and content layouts. Each content object had (in addition to normal fields) simple editable "content" attribute, which could contain any HTML. Of course, that HTML could also contain "transient tiles" with their configuration in querystring. If it did not make sense to serialize tile configuration as query string, a "persistent tile" could be used: it would store configuration in annotation and only have data-tile-reference in "content" attribute. So, everything content specific was mostly in "content" attribute.

2. Then Nathan implemented managed content layouts, which replaced "content" attribute with reference to centrally managed HTML layouts. Now, by default, the "content" attribute was not editable, so all tile customizations were stored into annotations similarly to "persistent tiles". Mosaic could still be used like 1), but by default all tile configuration and content was in object annotations. (Agreed that this was unexpected development just after we had consensus that only transient tiles should be used.)

3. Nathan's use case was a real one, so we needed a compromise. In Mosaic 2.0 there's separate attribute for layout ("customContentLayout") and separate attribute for "transient tile" configuration ("content"). Once again, annotation storage is only used for tiles inherited from PersistentTile. Also all existing peristent tile types are disabled by default (because our community cannot maintain e.g. image scale machinery for both content images and tile annotation images). Yet, effectively all tiles are "persistent", because of separation "customContentLayout" and "content" attribute. But querystring configuration is still used for default values and non-customizable site layout tiles.

[hvelarde]

@datakurre why do we have to chose among transient and persistent tiles? what do we gain by storing content in those "centrally managed HTML layouts" instead of in annotations on the object? what's the use case we are trying to solve?

IMO, by doing that Mosaic is moving in the wrong direction: instead of respecting Deco's original clean design, we are pushing it to try to fulfill requirements that are outside its scope as a layout editor.

I'm not against people solving their problems, I'm against core developers pushing their opinionated solutions into the core without enough discussion just because they can.

are core developers willing to maintain not only the indexing and image scale machineries, but now the versioning for tiles also? soon Mosaic will face many more issues as link integrity, export/import, migration and so on; trust me, we have been there before.

we need to spend more time sharpening the axe and less chopping the trees. yes, it will take longer, but the solution is going to be better and more maintainable in the end; let's not repeat the errors of the past, please.

yes, tiles may have content associated with them (rich text and image tiles are the most obvious examples of that); but that content must not be scaled, indexed or versioned, just because is not really content: just think about the site's logo and footer as tiles.

what do we want Mosaic to be? collective.cover lite or the new layout editor for Plone? a content type is a content type and a layout editor is a layout editor.

if somebody needs features of a content type, then write a content type instead of adding those features to the layout editor or we'll end with a Frankenstein monster.

we, for instance, need a configurable front page/landing page content type with scaling, indexing, versioning, link integrity and a clean UI designed for site editors that change its content dozens of times a day;, and we want to use the Mosaic as a layout editor for it: that's collective.cover 2.0 if we ever have the resources to build it.

please keep things simple for the sake of Mosaic's rapid inclusion into the core; future generations will thank you for that.

[tkimnguyen]

I don't know why I got dragged into this. Much smarter people than I are involved (i.e. you). I do see Hector's point: the complexity of reimplementing all that functionality into tiles.

[vangheem]

It was to be able to have multi-lingual support. Storing it in a field that is multi-lingual compat means that mosaic pages can be translated...

[djay]

@hvelarde I don't mosaic was designed to be a layout system like cover. where layout means it stores no content. Mosaic is meant to be a content type replacement which allows for different layouts.

@vangheem Seems like going away form a single html content storage has created problems. Single html storage would make history easy since most content is stored there and anything else is a reference. You just track the history of the content and references.

Perhaps there is a better solution for multilingual? Is the idea to translate each tile separately instead of the whole page together? Perhaps there is a way to merge the main mosaic page with a translated version such that it retains the layout information from the main page, but replaces all the content from the tiles in the translated page?

[datakurre]

@hvelarde

I recall, we agreed that persistent tiles and annotations should be avoided. Managing tile data in single attribute is easier. For example, when one really avoids content in layout, marking that single attribute "language independent" in plone.app.multilingual, gives translated content with synchronized layout.

Of course, it was like that in original Deco. But in Deco that single attribute contained both the custom layout an tile configuration. It was not possible to customize tiles without also customizing the layout. And that became a problem in real world. So, we separated them. Now "customContentLayout" attribute is only about the layout, and "content" attribute is only about tile configuration (and possibly content like HTML stored in those tile configurations).

If one did not use PersistentTile at all, and consider querystring configuration only as a way to define default values for customizable tiles, this could actually simplify things.

Our use case:

1) We use site layouts, and need to include required viewlets and portlets into layouts using transient, querystring-configured tiles. Those tiles should only be configurable by modifying the site layout. This was Deco from the beginning.

2) We also need site layouts with customizable non-removable tiles. A bit like the use-case of cover with predefined layouts with editable tiles, but those tiles may be all around the page and not wrapped with a Mosaic/Cover like grid. Deco didn't specify how customize configuration of tiles when there is no customizable layout.

3) Of course, we also need customizable panels / "content area layouts". Both centrally managed (to make them easy to use) and customizable with enough permissions (for flexibility when it matters). Deco didn't specify how to allow customize tiles without customizing layout.

Normal content pages usually require only 1). We are replacing our various "section frontpage" content types with folder/page with 1) and 3). All fancy front-pages require all 1), 2) and 3).

[datakurre]

About layout vs. content. If we accept Rob's Deco prototypes as a reference implementation of Deco, those were alwasy as much WYSIWYG content editors as layout editors.

[datakurre]

@djay Yes, single HTML content storage had benefits, and with separate HTML content storage for layout and other for tile configuration, we got some of those benefits back.

[hvelarde]

@vangheem I don't doubt it, but just because you're a smart guy and you can do it, it doesn't mean it's a good idea; you can put whatever you want on a browser view, even AI if you want, but… what's the point? are we building a new CMS on top of our CMS?

@djay collective.cover is not a layout system, but a content type to address the use case of a front page/landing page; it happen to had a layout editor just because there was nothing available at that time for such task; and no, neither Deco, nor Mosaic, were meant to be a content type replacement, but layout systems for Plone in the first place.

browser views are browser views, content is content; please don't come pushing for just another way to add content into Plone: we already have 2 content type frameworks (Archetypes and Dexterity) and 2 ways of extending them (schema extenders and behaviors).

instead of getting rid of viewlets and portlets we're inventing just another way to add content.

do we really have such a big problem differentiating what is content and what is presentation? I'll give a clue: if what you're adding into a tile needs to be indexed, translated, scaled, versioned, or migrated, then it don't belong there, but into your content type fields.

please let's stop mixing concerns and making things even more complicated; the sooner, the better. as @keul recently said: "I'm a time traveller that came from a dark future. don't do this, is a bad idea".

@datakurre do you mind to point me to the original Deco reference; I would love to read it over the weekend.

@plone/framework-team is time to start taking care about this.

[datakurre]

https://github.com/plone/plone.app.mosaic/blob/master/docs/Blocks.pdf

And rewatch Rob's demos

[vangheem]

@hvelarde hehe, well, you'll be happy to know then that I fought very hard to keep it as annotations but was overridden :)

[datakurre]

@hvelarde I feel that you are not listening.

Rich text and image tiles were in Deco from the first prototype.

We've already agreed that standalone image tiles were bad idea and those are already deprecated in favour of using content images and image fields in Mosaic 2.0.

For rich text it does not make sense to have dozens of rich text fields in a content type to allow free layout of text boxes. Original Deco stored all rich text within layout in "content" field. This was broken with standalone rich text tiles, but thanks to the new storage, all rich text is again in a single "content" named field. And the custom layout is now only about layout.

[datakurre]

About Deco and content types. @djay is correct and that was implemented in plone.app.page well before plone.app.contenttypes existed. In another reality Plone 5 doesn't have p.a.c., but only plone.app.page. But that future was lost with Jarn and Martin.

[datakurre]

@hvelarde Please, once you have read the Blocks manifesto, write your thoughts into a new community thread. I have no hurry to get Mosaic into core (the current add-on is good for me) so there's still time to get some consensus.

And regarding this issue. Diffing fields "content" and "customContentLayout" should be enough with the current version.

[hvelarde]

@rristow sorry for hijacking your issue ;-)

[djay]

@datakurre I think I understand. So now there are two fields, one for custom layout and one for content and somehow they get merged? And some times a layout is shared so the custom layout data is empty? That seems like a good compromise to me.

It does create a interesting UX problem of how to show the diffs of two different fields data on a single history view. Or does the standard history view already handle this? Showing layout changes visually is going to be tricky also.

@datakurre BTW, I don't think plone.app.page died, at least not to me. Plone.app.contenttypes was always temporary. We just need someone with the political will to guide us from p.a.contenttypes to p.a.page (+ images and files). and someway to make the transition smooth.... and some kind of replacement for the concept of a type (which is probably instancebehviours). We need a CMS that still has types but less rigid ones.

[datakurre]

@djay Yes. Currently they get "merged" by each tile reading its configuration separately from that field (yet, there's some caching). Merging them as whole is an option, if that is necessary for performance, but without merging the content field has benefits of annotation stored tiles without separate ZODB object for each tile. I feel that these pieces are still a bit moving...

I agree that while diff is technically possible, it's very hard to visualize.

Maybe plone.app.page get's a new change once blocks, tiles, and mosaic works well enough.

[rristow]

I changed the topic of this issue, because there is a much more been discussed here. Or maybe will be better to split this into another themes/issues? Anyway, we implemented a workaround for the problem with the history (#345)