we - yes thats pretty general, but valid - might be able to solve several "issues" about the whole theming/templating story.
to do so, we need to find out how to persist* blocks that should be visible on lots of (sub)pages.
by doing so, we can:
- get rid of viewletmanager
- get rid of generic setup (viewlets.xml)
- get rid of portlets
- get rid of metal-macros
- get rid of diazo (maybe)
- get rid of multiple ways to theme and simplify that topic
- by that we could reduce documentation too and
- help volto
- help mosaic
- help integrators and designers
you are triggered?
because i have no clue how to achieve that goal, but i wanted to talk about it. and during the alpine city sprint i had the chance to talk with jens, peter, victor, stefan and fred at the same time about this thing and nobody disagreed so far
lets talk "persiting" a block
i am not talking about storing a block, but making it - like portlets - traversable and persist and lock (so you can't re/move it) over multiple objects. while others are dynamic - a slot so to say. like metal slots where in the past and viewlet-managers are today.
maybe its just a rather simple field, that sits on every object, which is inherited downwards if an object is created underneath and/or changes happen. yes this needs to be handled with care and needs some thinking about how to treat inheritance and updates. like shall all subitems should delete the block if it is removed in one page...
i think the data-structure for the layout could be something json-friendly to help volto and any other frontend as they talk mainly json. a yafowil array compound field would fit the needs to manipulate this tree, rearrange groups and so on. even in plain plone. no fancy editor. but an editor would be awesome anyways. mosaic uses xml to store that and its no fun to traverse that for any purpose (find a block, change it, update it, crud data, add classes, whatever)
i will add stories, as i think this could help to understand the basic idea and how we might style plone in the future.