Plone.restapi and tiles

I just stumbled upon this feature of plone.restapi:

I really don't get the point and I don't understand the use cases.

can someone (@tisto?) comment on the rationale behind this?

plone-react has its own tile based layout implementation supported by plone.restapi. Mosaic stack is designed for server side rendered tiles, it make no sense to translate it directly into plone-react.

That said, I've been planning to implement Mosaic tiles expansions for Mosaic. One that renders tile configuration, another that renders tile html. My use case is building GatsbyJS-sites from Plone, but still keep allowing editors to build (limited) custom layouts with Mosaic. Whether I can make that depends on how well I manage to sell GatsbyJS-approach internally during the next six months.

1 Like

that's quite interesting and something that, as you may know, has been available in collective.cover since the first release (tile configuration).

my main concern is we seem to continue pushing content where it doesn't belong: those browser views AKA tiles. we will end with content type instances with some content in fields and some other embedded in the tiles HTML.

I never liked that approach, but seems that almost everybody using Mosaic love the idea.

1 Like

Yes, that's valid concern. I'm hoping that getting a few GatsyJS-based projects done from Plone content, would let me better think out-of-the-box to see how that could be fixed in the future.

Detailed blog post about why we implemented the tiles endpoint and how we are using in it Plone-React:

https://kitconcept.com/blog/pastanaga-editor-status-report-plone-beethoven-sprint-2018/

1 Like

so, you want to make a static site dynamic? I'm more confused now :slight_smile:

interesting indeed, but I still don't get the point; seems that tiles are a new name for fields and we are going to allow people using the CMS to insert any number of new fields on any piece of content.

IIRC, this has been the idea since the beginning of Deco, and it could make sense on small sites of just a couple of pages managed by one or two persons, but on others may be a nightmare in the making. I can't imagine migrating a site with dozens of editors and tens of thousands of news items, each one with a different layout and content fields (tiles).

you say:

This allows us adding more complex content elements such as images, videos, and in the future more complex layout elements.

In addition to the standard text editing it is now possible to add an image tile that can be placed on the left or right side, on the center of the page or in full page width.

Rob also added a YouTube tile that allows the editor to add a YouTube video URL and then displays the video within the editor and the page view.

Text, image, and video tiles can be added to a page. They can be deleted and moved up and down to change the order of the elements.

correct me, if I'm wrong, but I don't see anything that can't be done with our current content editor.

thank you for your comments, guys; I'm willing to learn and understand your use cases to see where are you heading.

some ideas may be useful for us in the future.

Obviously editors use Plone. But the current GatsbyJS+Plone -setup only allows layout programmed into Gatsby setup. Bringing a little more power back to editors would bring more use-cases for it for us.

I'd guess its about scalability. If you have 100 sites or 1000 sites you don't need that much cpu/ram for normal site users to view the sites and just keep a small plone cluster just to handle editing the sites.
But they can't you handle almost the same thing by just setting up varnish to cache every page for 5min + grace mode? @datakurre

I'm guessing they haven't finished the grid part where you can rearrange tiles side-by-side etc.
But if pastanga requires client-side rendered sites... then it's limited use-cases.

tiles aren't fields. They are more like table cells in tinymce or shortcodes in WP.
I don't know about pastanga but mosaic doesn't allow content editors to add fields. It allows either a fixed layout mode where the designer determines the layout and data is stored in fields, or if the permissions are right it allows the editor to "customise the layout" (which is just the equivalent of a RichTextField and tinymce), but thats just moving around grid cells (which might contain field content) but not add new fields.
This is also the reason for storing the tile data inside the html... because really its just a single RichTextField and all they stuff the editor entered richcontent and shortcodes.

That and everything. It’s also the next generation of platform independent theming experience. Conceptually a bit like diazo, but with GraphQL instead of XSLT.

1 Like

Bottom line is that building fast websites (especially for mobile) became a non-trivial task (PWA, ATF, lazy loading components, etc.). We can choose to do that all on our own or build upon something like Gatsby, that has all the necessary optimizations out-of-the-box and a rich ecosystem of add-ons (React).

We can put lots of optimizations into Plone and Plone-React. Though, the tradeoff between flexibility and speed is a different one for the standard Plone use case.

IMHO Gatsby is the answer for a specific use case and I am very much looking forward to hearing from @datakurre's real-world use case experience.

The new Pastanaga editor focuses on the user experience of the editor. A user friendly editor is more important than an editor that has all the features IMHO. We choose an agile approach of building a very basic editor first and then move on from there (see the other blog posts on the kitconcept blog).

For our recent Plone-React projects we already build client-specific and more complex "tiles", e.g.

https://www.zeelandia.de/produkte/urgetreide

My personal opinion is that the existing solutions already have too many features. I am not saying that everybody needs to agree on that. You are free to choose Mosaic, Cover, or any other solution. Pastanaga focuses on UX and our goal is to match the medium-editor or Gutenberg features. We build upon an existing technology stack (React, DraftJS, DraftJS plugins) so that we don't have to reinvent the wheel. We are looking for likeminded companies and individuals who want to use modern web technology to allow Plone to provide the most user friendly editing experience of all Open Source CMS.

I agree that there is an overlap between fields, behaviors, tiles, and Plone-React tiles. As always in the Plone community, we solved a single problem in multiple ways (and used technology like behaviors in a way there were never supposed to work).

Though, with plone.restapi and plone-react we just can not fix all the problems of the underlying stack. We have to build something on top of what we have and live with its shortcomings for now. We have a stable REST API for Plone now that would allow us to rip out lots of things and clean up the entire backend. Though, I think it is too early for that. First we have to finish the frontend story and ship it with Plone.

3 Likes