"Render" JSON of URL


#1

Enonic version: 6.15.3
OS: OSX

When using template-engines as i.e Thymeleaf we would loop through the page region(s) and then do data-portal-component="${component.path}". The same goes for layout. For each “component” we return a body which is the rendered page/layout/part.

Is it possible to do the same by using JavaScript and get a single JSON representation of the data needed to render a URL?

Use case: Running XP headless for more than content types.


#2

Are you saying you want to access the raw page component JSON?


#3

What we need is to be able to get the output as JSON instead of HTML.

I’m not sure if this is even possible, but in the same way we’re able to control the HTML output of each page->layout->part we would like the output to be JSON.


#4

Only HTML output is post-processed (i.e. for processing layouts and parts). To better help you, maybe you could tell me what you want to achive instead - what is the use-case?


#5

I’m aware that this is an edge case, but what we need is to be able to use Enonic XP headless with more than just content-types as the we’re (probably) not going to render the actual page inside Enonic XP, but use it as a “content and page builder”.

I.e: When i’m requesting a XP service with a path for my “home” page, i would expect it to give me a JSON document which contains all the information needed to render it “somewhere else”:

Naive JSON example:

page: {
  config: { ... }
  layouts: [
    {
      config: { ... }
      parts: [
        {
           ...
           type: "article-list",
           articles: [
             { ... },
             { ... },
             { ... }
           ]
        }
      ]
    }
 ]
}

#6

I see! There are multiple ways to do what you need:

  1. Return JSON on request to actual path: You should easily be able to do this by ensuring clients include the accept header https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept specifying mime-type for JSON. Then add special handling for JSON requests (as opposed to HTML) and simply return a JSON response containing more-or-less the raw JSON from the current content.

All the page configuration is available there, so you can use it in any other client. NB! This will also give you the freedom to include standard templates that the editors can see and use when producing content.

  1. Use Guillotine: A better approach imho is to get these data from the Guillotine API instead. Some of the reasons Guillotine will work better is by processing links and html-areas so that the URL’s are generated properly. We have seen that it can be cumbersome to access the page objects the way the API works right now - but this can quite easily be improved by us if needed!