We need to support json output, similar to the current jsonFront outputType, which will be used by iphone & android mobile.
This will provide json output that should support specifying layout & styling information for the page. We currently have much of the information, but can only output the code in the order that the features exist on the page.
Really, we need the idea of a page which has the various layout regions, each of which can contain chains or features. The json spec we are working toward is here (in very draft mode): http://confluence.washpost.com/pages/viewpage.action?pageId=8032995
In particular, we would like to support the "regions" part (aka layout regions).
It seems like a simple & useful way would be to support a jsp that is associated with the layout. E.g., the homepage.json layout can also specify a jsp. Then for each region, an array of items would be made available. Items might be a chain or a feature.
This is simllar to how the chain wrapper jsps are used.
Stephanie Clark
| I need it... | Week |
You are right. The down side would be that all the business logic in the jsp will have to be translated to the middle layer I'm suggesting.
My argument was that I think it's still worth while to do that once, since it gives the site team the freedom to produce whatever json payload for the receiver regardless of PageBuilder's limitation. Also it frees pagebuiler from maintaining another layer of rendering tier.
re: pagebuilder structured API; one issue with that is the business logic currently contained in the jsps, specifiying how features are displayed individually, or within chains.
Additionally, the json output is structured according to the needs of the receiver.
Both of the above are reasons to allow all the info necessary to be available to the jsps.
The bigger problem here is we need a way to some way to expose the rendering data (order of the layout/features/chains) and all the content with the edits that's associated with it to the mobile apps.
And currently solution is to have write bits and pieces of JSPs that generate parts of a JSON object, which come together to form a single JSON object response (via PageBuilder).
Which I think is not a sustainable solution (the part where we are building a json response using JSP). JSP is meant for rendering HTML which is a unstructured data, where as JSON is a highly structured data.
It might be better for PageBuilder to produce a structured API that spits out all the relevant rendering data including the content and the edits and have a middle layer that transforms that data for mobile apps to consume.
This approach has pros and cons.
Cons: We have to create and maintain a separate app that sits between pagebuilder and mobile app.
Pros: ᅟWe don't have to do a major refactor of PageBuilder to support a single use case. And site team is no longer bound to the limitation of PageBuilder rendering engine to produce the json that's required by the mobile team. (Also, you no longer have to produce a single JSON object using fragments of JSPs.)
I think the pros far out weigh the cons.
Let me know what you think.