If you are interested on hearing or discussing about the current state and future of Plone Mosaic, please, choose your favorite slots for possible open space at Plone Conf next week:
Please, be aware that there are only limited amount of open space slots available at the conf and I cannot quarantee, we get the slot with most voters.
At the open space, I can demo how I currently use Mosaic as a framework for WYSIWYG editing experience, but otherwise I'd expect the open space to be pretty technical. I'll recap the history of Mosaic and reasoning behind the changes between 1.x and 2.0, and what I'd like to add into 2.1. Then we'll propably fall into rabbit hole of all the current issues with editor and release management
Just a reminder: we have a Google Doc where folks have been signing up for open space slots and the info there should be transferred onto the signup sheets (real paper!) at the registration desk. As of today, the real paper ones are the definitive reservation system
@jensens@alert At the open space there was some concerns about moving from
annotations to attribute storage and using JSON to encode tile configuration.
JSON was introduced in hope of making it easier to experiment with new editors, but to be honest, currently it just burns cpu.
While I would not go back to annotations, (I’m expecting some performance benefits from “pre cooking” more tiles somewhat similarly to the rich text optimization I mentioned), I’m all for dropping JSON there and using the original querystring serialisation instead. It’s not pretty either, but that at least been supported by plone.tiles from the beginning. That should be easy migration and allows dropping plone.jsonserializer in the next major release.
Overall the situation of bypassing the usual storage is problematic. While annotations were meant to be a solution for this problem, they introduce others.
I don't like the idea of storing query string serializations. This is so ugly. And anyway, it is just another serialization that burns CPU?
We want it fast, so we should store it as a pickled dict? This works as long one always use a fresh dict instance for each change. Anyway, no idea which new caveats this introduce. But to me, it sounds sane.
Overall we have no benchmarks if JSON is really slow vs. query string vs. direct storage.
Storing as a dict sound like the same as annotations, but storing as a single attribute instead of object per tile data dict. Sure annotations could be reconsidere. They did allow concurrent writes of tile data, and Castle CMS seems to be ok with just using big connection cache for keeping them warm.
I'm still considering ugly query string serialization, because that's been in plone.tiles from the beginning and the serializer in plone.tiles is pretty well tested. But I admit, I have pretty blind belief in the original HTML-based Deco manifest. I'd also like to use it to optimize the rendering in the following way.
In Castle CMS:
Static (shared and centrally managed) content layout may contain tiles with syntax
data-tile="./@@tiletype/tileid?var1=foo&var2=bar"
When a content with that static layout is created and tile configuration is customized, values from that querystring are use as a default value, but customized values are saved as tile annotatation with id tileid.
When content is rendered, tile is called with URL ./@@tiletype/tileid?var1=foo&var2=bar, but data from annotation storage is preferred over the default values from query string.
I'm thinking, if we could go back to original transient tiles idea with the following
Static (shared and centrally managed) content layout could still contain tiles with syntax
data-tile="./@@tiletype/tileid?var1=foo&var2=bar"
When a content with that static layout is created and tile configuration is customized, a tile URL with customized values would get saved into content attribute HTML storage
When content is rendered, tiles from content attribute would be merged into layout after "panel merge", so that before "tile merge" tile URL would look like good old transient tile
data-tile="./@@tiletype?var1=hello&var2=world"
With query string serialization, this could be done without de/serialization in 3. and also tile rendering could be done without tile data lookup.
