Greetings, oh Great Hive Mind of BloomReach Realm™.
I need to be able to use two different templates to render the same document, with templates being selected depending on the URL used to open the document.
For example:
URL A: /some/folder/path/to/my-document → render using template/page A
URL B: /some/folder/path/to/my-document/tryitnow → render using template/page B
I’m not precious about the actual shape of URL B but the above is what I had on mind - URL B would be similar to URL A, i.e. still reflecting the original document’s path, but with a suffix or a query parameter to differentiate the two.
The thing I’m trying to avoid is having one template with conditional logic in it; I’d rather delegate the choice of which template to apply to the sitemap engine.
The more important reason for wanting the second template, however, is to have it inherit from a different base one (or none at all; this is to be decided) - something I can’t achieve through conditional logic within the template, AFAIK.
My sitemap makes use of _any_/_index_ to expose documents of mixed types stored in the same folders of the structure arbitrarily defined by the authors.
My doc type (website:apispecification) is referenced under /hst:hst/hst:configurations/common/hst:sitemap/_any_/_index_.
So far, I was unable to figure out how to configure the sitemap correctly and any suggestions or pointers to relevant concepts are welcome; this is the first time I have to modify the sitemap beyond the most basic scope.
Is this thing even possible within the sitemap like mine?
The sitemap in question: https://github.com/NHS-digital-website/hippo/blob/pds_api_spec_epic/repository-data/site/src/main/resources/hcm-config/hst/configurations/common/sitemap.yaml
Rafał
I believe you need 2 sitemap items, each with their own hst:componentconfigurationid or template. The more-specific sitemapitem “wins” and changes the componentconfiguration/template.
Please review https://documentation.bloomreach.com/14/library/concepts/hst-configuration-model/use-index-sitemap-items.html for potential sitemapitems like:
-
hst:sitemap/_any_/_index_ has an the “base” hst:componentconfigurationid
-
hst:sitemap/_any_/tryitnow has an alternate hst:componentconfigurationid
This assumes you have the property hst:relativecontentpath configured to match/find document “my-document” on both sitemap items.
Hi,
be aware that _index_ is only possible to be configured as a child of a _default_ sitemap item.
If is acceptable to have the fixed sitemap item in the beginning like /tryitnow/some/folder/path/to/my-document then the configuration should be much cleaner
Thank you, Gentlemen.
Before asking the question, I tried Brian’s approach and didn’t manage to get it to work. I then tried to modify it to have _default_ (as suggested by Saimir and others), still to no avail.
You did, however, confirm that I was thinking along roughly the right lines and that, with a bit more perseverance, this should be possible - thanks for that!
I like Saimir’s suggestion about sticking the fixed prefix as the first component of the URL rather than as the last one. One thing that this would give is the ability for the Component/Controller to receive an instance of the matching document for free (which is what I originally wanted).
After some consideration, I ended up implementing yet another way, however:
In my case, URL B is exposed as a hyperlink on a page opened with URL A. Clicking URL B opens a popup window backed by the same document, but presenting a radically different view.
What I actually implemented was to make the URL B consist of just the static component /tryitnow. Rather than relying on the sitemap to make the document available to the component backing the popup, the main page’s component (A) adds a reference to the document as HttpSession's attribute. URL B opens the popup and loads its backing component (B). Component B then retrieves the reference from the session and adds it to HstRequest as document attribute, thus making the document bean available to the popup’s template.
One consequence of this is that, in order to open the document in the popup, one has to go through the ‘main’ page (URL A). It goes against my original thinking, but I realised that, in my particular context it’s actually an advantage, and so I settled on this solution. The reason it is a good thing is because the main document is required to provide extensive, textual content, whilst the popup only offers some interactive functionality where it’s useful to see the text in the main window, side-by-side with the popup.