Persisting Blocks to solve it all?

Development User Interface
1

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?
good.

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 :wink:

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.

2 Likes
2

block types are already there, but i think of abstracting that down a bit.

not sure where that leads and i am pretty sure, i am not the first to think about that.

  • RichText
  • Media
  • List

RichText is self explaining. as is in volto and mosaic. but no media in there. but lets allow variables like in easynewsletter with {{a_var}}

  • Logo linked to home for example

Media like Image, Video or Audio, depends on the given data. (instancebehavior might help there to add the proper interface based on the data)

List is anything listable.

  • a list of entries inside a container (folderish page or folder - no matter)
  • a list of entries by a query (think collections)
  • a list of manually selected and arranged/sorted items from all over the website - even mixed

Lists should allow variants (yes - like in volto).

  • because a slideshow is just a list of images.
  • or a carousel of news-items
  • or a gallery
  • or a tree, which is just a nested list (navigation portlet/drop down nav)

more to come ...

3

CastleCMS uses “slots” instead of portlet managers and you put (Mosaic) tiles into them. They inherit down too. Similar idea?

4

not really as far as i understand it.

castle is not plone, not mosaic, not volto - or am i missing something.

i would like to see the portlet-story, viewletsmanager-story and the overall hassle on theming gone for good, by reducing this down to its basic to make composition of a page easy for integrators and editors and achieve compatibility between plain plone, mosaic editing and volto.

maybe i am ahead of time as i would also say, the blocks should be a flat structure, as you can do a lot with css now. no more need to nest to invinity :wink:

but thanks for your input. it might still be interesting to take a look at castlecms to get an idea about the conceptional basics.

5

CastleCMS is Plone, enhanced with many back end features (e.g. integration with Redis and Elasticsearch), and on the front end it is Mosaic and React.

1 Like
6

What is the current status of Castle? Running under which version of Plone? Is actually maintained and in continuous development?

7

I don't speak for them anymore but it is being maintained, yes, and as I understand it they are working on getting it onto Plone 5.2 and Python 3 (there is a branch there already but it is ~1 yr old).

Whether they continue to work on it, I don't think is relevant. We can still take the ideas and the code.

8

i see ... and want to see the base implementation within plones abilities and others using it (like mosaic and volto or even castle) because to me this topic is about the overall theming and templating story in plone.

i know this is again an attempt to done several times, thinking of collage and others

9

Would be very useful.

One thing to remember: making portlets is (in my opinion) much easier than making 'normal' blocks, so it is probably a bit of work to 'port the portlets' ?