After some brainstorm sessions, also related to HST REST API support, we concluded that storing the actual hst:component tree directly below the document prototype is undesirable : For example if want to have three different XPage layouts for some document type, we'd have to create 3 times the document type to have 3 different prototype documents containing 3 different XPage layouts.

From HST REST API pov, you'd like to be able to create or add XPage layouts via HST REST API invocations, but it becomes really awkward if these invocations would modify the document type model: we'd have to blend two API's.

Instead we came up with the following idea:

1. A document prototype only contains a marker interface like the current 'hst:page' mixin to indicate that it is an Experience Page
2. When a prototype is selected containing the Experience Page mixin marker, the CMS UI should show a dropdown of available XPage layouts to choose from

Note 1 is debatable since it might also be driven by folder type instead of information on the document prototype

Technical approach

The available XPage layouts are globally, not just for channels but even for site wars, thus will be stored somewhere below hst:platform configuration. In CMS Wicket code when creating a new XPage document, we have to support a dropdown to select a layout from. Same has to be supported when creating the XPage document from the Channel Manager. Since the HstRequestContext is available showing the available XPage layouts is not so hard. The repository workflow that handles the creation of a new document from a prototype most like should get a callback handler support through which downstream projects can include extra behavior. The HST in this way can inject the XPage layout into the document based on the chosen XPage layout

Note

I think in the CMS we already have for some documents during creating an extra dropdown select box. We'd need this for XPage document types as well. Not sure if it should be based on the hst:page mixin in the prototype or in the page definition itself (and that it can for example be marked in the document type editor that a document type is an XPage or not)

Designs

wrt the third design, the right version with radio button seems to best fit architecture since inheritance is complex. To be discussed is whether only during document type creation you can decide whether a doc type is an xpage or not

1. https://bloomreach.invisionapp.com/share/N4WCV1BEUXC#/screens/413517056
2. https://bloomreach.invisionapp.com/share/N4WCV1BEUXC#/screens/409585313_0520_Create_XPage_-Create_Document_Step_1-
3. https://bloomreach.invisionapp.com/d/main?origin=v7#/console/19555213/413517052/preview?scrollOffset=0