WIP: Technical approach for publishing 'flexible pages' - #183
ChrisBAshton wants to merge 1 commit into
Conversation
3d8ea05 to
8b8f59c
Compare
|
|
||
| In this design the schema defines a number of page regions which can be populated by one or more sections. | ||
|
|
||
| ### 2. How strict should the Publishing API content schema be in enforcing the content? |
There was a problem hiding this comment.
This can then be either:
document_type: history_page
schema_name: history_page
// presence of certain components can be required-> in which case when there is a request for new document types, a step in the dev wokflow will have to be adding a new schema to Publishing Api.
or
document_type: history_page
schema_name: flexible_page
//nothing can be required, everything is allowed, as long as it is a recognised "building block"/component/item/element or whatever name we land on-> in which case we only have to register a new document type but we can reuse the schema. This separation means we maintain open the future possibility of amending this document type, making things required if we want or reorganising the layout. This allows us to cater to different document type needs.
or
document_type: flexible_thing
schema_name: flexible_page
//nothing can be required, everything is allowed, as long as it is a recognised "building block"/component/item/element or whatever name we land on-> we cannot treat a history page any differently from any other page. There is basically no history page.
Does the URL we want to serve these at enforce how we understand the "document_type" (technically and semantically)? Meaning, if we want to serve all history pages from /history_pages/... then they need to be grouped as such?
There was a problem hiding this comment.
That's a good point about the URLs. I would imagine your option 2 above will be the best bet, which I believe is how specialist documents work.
8b8f59c to
947afbe
Compare
| Factors in favour of hosting flexible page publishing in Whitehall: | ||
|
|
||
| 1. Whitehall has the most mature feature set. Extending the Whitehall edition model would enable flexible pages with the full publishing workflow, including scheduling and 2i. | ||
| 2. Whitehall is the most commonly used publishing tool, so publishers will not need to adapt to a new tool. |
There was a problem hiding this comment.
I wonder if there's an additional benefit to Whitehall, in that it has fairly robust support for assets (e.g. uploading images, cropping them etc.) which AFAIK specialist doesn't have.
I imagine assets is going to be a big part of this whole shindig.
We will iterate this draft RFC as we work through a series of mini technical spikes, and eventually aim to open it up for review, to go hand in hand with the frontend RFC (RFC-182).
947afbe to
e7ec1d9
Compare
4 participants
See rendered version 💅
We will iterate this draft RFC as we work through a series of mini technical spikes, and eventually aim to open it up for review, to go hand in hand with the frontend RFC (RFC-182).