Dynamic include pages in DXA

Question

We are having a requirement to include dynamic include pages based on the URL pattern or publisher controlled

Example: If I hit a page https://domain/context/sub1/sub2/sub3/page.extension; I should retrieve a couple of related pages like https://domain/context/sub1/sub2/sub3/include.extension.

I was thinking about 2 approaches.

Approach 1 Get a new page model based on the URL. If the page model is available for the localization, do a partial view model rendition as a string for my area and my view. We will use the underlying DXA code to retrieve the page model from the broker so any cache will be preserved.

Approach 2 Get a include page with a delimiter like ~ and extend the default DXA default provider (GetIncludesFromModel) class to process sub1/sub2/sub3/include.extension based on the incoming URL instead of ~include.extension. In this approach, I would have an include page for the page template as something like '~include.extension' and it will be available in the settings.json. We can process the URLs from the localization and the include page objects.

Publisher controlled As an optimization to approach 1 & 2 (publisher control the includes), we can have the publishers include these URLs in the SG metadata (if not based on the URL). By including the "Add inherited metadata to page" TBB, I assume that the relative URLs will be available for me to look up the page model. This would mean that they have can any page/s mapped to that region for all pages in that structure group. We can have them at page level as well but that may be one too many metadata to manage.

I could not think of any solutions in the CM side given how DXA includes works.

Note: Having the components embedded in the page as dynamic assembly is NOT going to work since users may not know the need for this component presentation.

Update: We do not have SmartTarget available in our platform.

Am I missing any other obvious solutions that I can explore with DXA Core? Votes on approach 1 vs 2 will be appreciated as well. I have a feeling that approach 2 is more thread safe given how DXA region mapping works (will put in a bug if we do find one). Approach 2 will also add all of the regions to the page model when building it the first time vs. approach 1 may create and generate a new page model.

Answer 1

In general, if you need custom logic for how Page Models are constructed, I would recommend using a custom Page Controller (can be a subclass of Sdl.Web.Mvc.Controllers.PageController which overrides the Page method).

Creating a custom Content Provider requires you to use a non-public extension point which may change considerably between releases (as a matter of fact, it will change considerably in DXA 2.0).

I don't think your CM-side solution will work, because include Page URLs are in the metadata of the Page Template, not of the Page itself.

On that note: wouldn't it be an option to just use different Page Templates (which might use the same Page View)?

Answer 2

How about adding a smart target region for header and footer.

Set different ADF Claims for each different condition( it could be URL Pattern or any business criteria) and just add smart target triggers for those header and footer ST regions.

In that way, you can meet your business requirements and also continue using OOTB DXA as is :)