Preliminary

XPage hst configuration are a composite structure of hst components. An XPage config for PaaS is in the realm of developers, aka ONLY allowed directly below the hst:configuration node (outside the hst:workspace), in SaaS XPages are 'runtime/production' only, hence are stored below hst:workspace. We do not support XPage hst config at the some time in hst:workspace and outside the hst:workspace. It is EITHER one of them. XPages configs are only allowed to be stored below hst:pages for now, both for PaaS and SaaS. Debatable whether we need to allow them in hst:abstractpages (for PaaS?) or below a new section 'hst:xpagelayouts' or 'hst:xpages' for Saas/PaaS. Since they will be stored below JUST one 'grouping' node, XPage can be looked up by jcr nodename!

Note

The below depicted design is how we initially implement it for SaaS and PaaS : the only reason is to be able to deliver the feature in PaaS. After this, we will rework the SaaS solution to again get rid of the hst:xpages section (and also hst:components and hst:abstractpages and hst:prototypepages!!) and drop everything in the same bucket. Since now implemented with PaaS in mind, we only allowed XPages layouts directly below hst:configuration and not below hst:workspace

Storage Design

The XPage layout should never be stored below the XPage document variant: Namely, the Xpage layout should be possible to be modified in the future by a HST REST API developer without requiring existing XPage documents to be updated. Therefor, something like below (not cast in concrete) is needed as storage:

+ hst:configuration
    + myproject
        + hst:xpages
             + xpage1 
                + main 
                      + container1 
                          - hst:qualifier = abcd
                      + container2
                          - hst:qualifier = dcba

when using such a XPage layout in an XPage document variant, the XPage doc variant looks something like:

+ mydoc
     + mydoc (preview)
         + hst:page
             - hst:pageref = xpage1
             +abcd 
                  + banner1
                  + banner2
             +dcba 
                  + banner3
                  + banner4

With the above info the hst:page can in combination with the current channel be resolved to 'xpage1', and when loading the 'xpage1' page in request based HST page model, banner 1 and 2 can be substituted in container1 and 3 and 4 in container2