Mosaic, Persistent and Transient Tiles and saving layouts as templates

[datakurre (Asko Soukka)]

@fredvd

I'll have to reread and try to dive into the code to understand your last explanation about transient tiles being saved as 'faux' layout on another attribute, but I'll get to understanding it.

Try @@tile_layout_view with Modify portal content permission. It is an introspection view to render only the 'faux layout' (all saved transient tile configurations). Because changing layout does not remove tile configurations (that's by purpose to support layouts with matching tile ids to just reorder known tiles without removing their configurations), that may contain uncollected garbage.

@fredvd

It makes not much sense at the moment if you need local tile configuration data to not use PersistentTile as the tiles data is persisted in an annotation anyway.

It has difference on ZODB connection client cache. Tile data is persisted as part of the context object. PersistentTile counts as one extra object per tile.

@fredvd

If you don't use PersistentTile, complex schema fields like relationChoice for a related items widget will throw an error by the transient tile as it still tries to serialise the data and throw a jsonencode error. If you switch such a tile to PersistentTile, all is fine.

Agree on that. JSON-serialization part was a mistake (it looks a bit better that querystring serialization, but does not really add any value). It was supposed to ease transition to newer editor that was developed during the same sprint, but that didn't happen. Yet, if it was not JSON-serialization error, it would have been querystring-serialization error. That said, it will help to implement REST API expansion for Mosaic tile configuration...

I have only used (serializable) UUID values for relations in tiles. Relation values, in theory, could allow backlinks knowledge and prevent link breakages, but I doubt it currently happens, because acquisition chain is broken for them (I don't really know what is indexed into relation catalog for relations in tiles).

@fredvd

If I put this in the content layout template, and apply it to a content item as layout a tile is present, but the first file rendering is completely empty.

That sounds wrong. It should always use query parameters unless matching keys are found from annotation. That said, X-Tile-Persistent should always be unnecessary for PersistentTiles. As told previously, it was made for Castle CMS to make transient tiles use persistent tile data storage.

@fredvd

The linktile1 ID in the data-tile attribute is necessary.

Yes. The part after tile type name is tile id, which is used as part of the key when saving the tile data. If you had multiple content layouts with matching tile ids, you could switch between layouts similarly to switching between views (all those layouts would use the same tile configuration for matching tile ids).

@fredvd

there's no reason not to use persistent tiles in mosaic 2.0

Possibly so Maybe persistent tile experience could be enhanced.

Btw, I wonder, how I recall @hvelarde warning us about embracing the use of persistent tiles, not the opposite. Maybe that was when versioning of blobs in persistent tiles caused issues... Anyway, I've been mostly using TTW regular tiles provided by collective.themefragments.