DXA 2.0 backwards compatibility testing

DD4T.Providers.DxaModelService DLL is built with dependency on DLLs that are not added to the dependencies section in the Nuspec. Dependencies used in the DLL, are:

• DD4T.ContentModel 2.2.1
• DD4T.ContentModel.Contracts 2.2.1 (I installed Nuget version 2.2.2)
• DD4T.Core.Contracts 2.2.2 (I installed Nuget version 2.2.7)
• DD4T.Utils 2.2.2 (I installed Nuget version 2.2.7)
• Tridion.ContentDelivery 10.1.0.1003 (Nuget version 10.1.0)
• Sdl.Web.Delivery.Caching 10.1.0.1003 (Nuget version 10.1.0)

This should be reflected in the Nuspec so they are installed automatically. The result right now is a type loading exception. 

Workaround is to manually configure bindings in the Web.config, but this shouldn't be necessary.

ASP.NET MVC presents the URL to the action method WITHOUT a leading slash (so 'en/index.html' instead of '/en/index.html'). In DD4T, the slash is not prepended to the URL in the framework itself. Instead, it is normally done in the concrete controller implementation (in other words: the customer knows they have to add the leading slash themselves).

The DXA 2 model service provider (I think it is in the provider, could be in the client as well) prepends the slash to the URL itself. As a result, all existing implementations return a 404, because the URL that is looked up in the broker, is '//en/index'.

Page cannot be deserialized when JSON is generated by DXA R2 TBBs. The error thrown in the application is 'Value cannot be null, parameter name: source'.

The line that causes the error, is made red below (from the ContentModels.cs class file in DD4T.Model):

[XmlIgnore]
IList<IComponentPresentation> IPage.ComponentPresentations
{
get { return ComponentPresentations.ToList<IComponentPresentation>(); }
}

Looking at the JSON generated by the model service, I think it is simple: the conversion to DD4T-style JSON is not happening. The DD4T and DXA2 models are the same for the top level properties of the page (like Id and Title) but fail on the ComponentPresentations element, which does not exist on that level in DXA2.

Update QS 23 Jan: the root cause has been identified by Alexey: it fails if the navigation.json page is not published. Since the point of this compatibility is to support existing DD4T customers who want to profit from the model service, it makes no sense to force them to create this page and publish it (they probably have an alternative navigation mechanism in place already). We need a version of the model service that does not fail when the navigation.json page is missing.

Update QS 23 Jan (later on the day): the process also needs schemas.json. Bart is recommending to publish the Publish Settings page, which in turn publishes the above-mentioned JSON files as BinaryVariants. We will do that and retest.

Update Jan 25: When running a dd4t-2-java app against http://ec2-52-17-130-35.eu-west-1.compute.amazonaws.com:8081/content.svc, it seems that the ModelService doesnt convert PageTemplate info. We need to decide whether this is a blocking issue or not. Quirijn Slings - we first also need to know how this page was published (with DXA or DD4T TBBs)

Update Jan 30: everything works if a. you have published the publish settings page and the navigation page, and b. you have assigned DXA metadata to your DXA page template. This is something that must be made clear in the release notes.

Note that the DXA page template that we used on this page, has metadata assigned to it. 

Model conversion (to R2) fails if page template has no metadata (which is a valid scenario in DD4T). 

The error is in the class ToR2ConverterImpl, in the _loadIncludes method. Please check if the pageTemplate has metadata at all before checking if it contains a certain field.

2 - 

TSI-3014

TSI-3032

WORKS NOW! In all scenarios the model service is able to resolve links. The behavior is highly configurable now, since the removal of namespaces (including the xlink:href with the tcmuri in it) and the link resolving itself are controlled by separate properties.

Links are resolved in the model service. This makes it impossible for customers to write their own linking logic, which many of them have done. Please make this a configurable feature and default to false.

DXA publishes rich text like this:

<p>Hello <a href="tcm:90-123">world</a></p>

It resolves this into:

<p>Hello <a href="/world">world</a></p>

Although this is great, DD4T has link resolvers in the application which expect xlink:href attributes. The rich text should therefore be resolved into this:

<p>Hello <a href="/world" xlink:href="tcm:90-123" xmlns:xlink="http://www.w3.org/1999/xlink">world</a></p>

NOTE: latest version allows you to chose whether or not to resolve links AND remove namespaces. SDL is still discussing internally whether to split these to settings into:

1. Resolve links (true or false, if true adds href="URL" without a namespace)
2. Remove XMLNS (true or false, if true removes all namespace declarations and all xlink:* attributes)

WORKS! See also issue 2.

The model service resolves links in rich text as well as the LinkUrl property in the DXA model, into hyperlinks without an extension. I understand why, because it is clean and many customers want it that way. But there are customers who currently route only **.html to their DD4T page controller. For these customers, the links will not work.

Could you make this behavior configurable? E.g.:

dxa.defaults.converter-extensionless-urls=true|false

It can default to true, so the default behavior remains the same as in the CTP.