You should expect more than just content from your REST APIs. With “Layout as a Service”, or LaaS-ie (groan), you can get the benefits of a traditional CMS-driven experience with the developer friendliness of CaaS. Layout as a Service makes app/CMS integrations (including previews) extraordinarily straightforward. Scroll down to “The Goods” for example code.
The problem comes along when business users need to see a whole layout in CONTEXT to manage content effectively, very much like traditional in-context editing, and when users require more control over the layout, order, and presentation of their content than a single CaaS call will allow. In fact, they need to manage something very much like a page made up of different content objects, but it needs to be machine consumable in order to be delivered properly in other applications. >Concrete example: we recently had a customer whose business users were in charge of managing not single content objects, but lists / carousels of different content objects, with specific graphical headers, based on visitor personalization and contextual data - think Netflix movie lists. Business users needed to be able to generate lists and respond in an extremely agile way to fast developing marketplace trends (say the death of a beloved performer) and the business needed to be able to manage and order the lists of the carousels (managing the list of lists) so that they made sense for the visitor. And, insult to injury, the resulting layouts and lists needed to be displayed not as pages, but in apps and set top boxes, some with limited HTML markup capabilities.
Layout as a Service (LaaS) takes the best of a CMS-driven experience (easy templating, server side contextual rendering, workflow, personalization, rule and permission-based content delivery) and marries it with the developer friendliness of Content as a Service. In dotCMS 4.2, you can call any page and receive the full page payload back as a single JSON object, including:
Not only that - and here is the magic - you can tell dotCMS to render the results and return the rendered results as JSON to you so you can use the information to paint your screen as needed, with very little effort.
Let me show by example - Take a look at the lowly “About Us” page on the dotCMS demo site:
While it looks simple, this page is virtual, and is actually made up of multiple content objects and content areas which come together to form the page. Feel free to alter the layout and content of this page by logging into the https://demo.dotcms.com site, going to “Browser → /about-us → index“ page and clicking on it.
This should take you to “Edit Mode” which looks like this:
You can see all the editable content, content areas (containers) and you can control and manage them, even adding dynamic widgets to them. This is all boilerplate CMS stuff. Go ahead and play around. Editor’s note: New DnD Layout/Edit Mode coming Spring 2018!
If you are interested, click on the edit template link on the left - this will let you manage the page layout on a screen like this. You can add rows, columns, headers, footers - basically control the layout:
Once you’ve had your fill of CMS based editing, take a look at this code:
This code basically calls the whole page you were managing via a RESTful API - here is the API URL:
The final result, all rendered client side:
The important point to take home is that the content managers are still empowered to change the layout / template of the “About Us” page in the source CMS, add rows, columns, edit and reorder, show / hide the header, and we can use their chosen layout to drive or hint towards our programmatic layout via the JS code above. Feel free to play around yourself. Add a row, reorder content, hide the header. It will all work.
Now, because dotCMS is an open source Java-based CMS, if you don’t like the way certain aspects of layout API, you can always write your own OSGi based Jersey endpoint. In fact, the original POC Java code for this work is available on GitHub, but that is a blog for another day.