Versions Compared

Old Version 6

changes.mady.by.user Quirijn Slings

Saved on

compared with

New Version 7

changes.mady.by.user Quirijn Slings

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Model

The generic model (IPage / IComponent / etc) should be ported to the new framework. Since the model service from a DXA perspective shouldn't use the generic model anyway, there is no conflict.

This applies to the default implementation of the model as well as the contracts. In many implementations the implementation is used instead of the interface, because the interface is read-only.

FactoriesDD4T 2 has factories that give access to generic types (IPage, IComponentPresentation, etc). This is indispensible, so we must include this in our facade.
ViewModels (factory + attributes)The entire ViewModel layer must be included in the facade. That - combined with the fact that the PageFactory / ComponentPresentationFactory are also in the facade - will guarantee that the DD4T ViewModels will continue to work.
Caching

The ICacheAgent interface must still be supported as well as the DefaultCacheAgent and NullCacheAgent implementations. This should not be a problem.

Should have: support for JMS listener approach (unless DXA 2 contains a better alternative for cache invalidation).

ConfigurationThe IDD4TConfiguration interface must be supported. The exposed properties (settings) must be mapped to the new settings in DXA 2.
Link resolvingILinkResolver and DefaultLinkResolver must be supported.
Rich text resolvingIRichTextResolver and DefaultRichTextResolver must be supported.
Publication resolvingIPublicationResolver and DefaultPublicationResolvermust be supported.
MVC
  • ModelControllerBase, TridionControllerBase and DD4TControllerBase must be supported (as these are the basis for most DD4T implementations)
  • RenderHelper must be supported (essential for all views)
Binaries

The DD4T approach to SDL-managed binaries is to store them on the file system when they are requested the first time, and serve them from there on subsequent requests. This approach must continue to be supported. Support for the BinaryDistributionModule is optional (it's also fine if this is replaced by a better alternative).

Image resizingImageHelper.ResizeToWidth should be supported (or an alternative must be offered) → only affects views so lower prio
XPM
  • XpmMarkupService and XpmExtensions should be supported (only affects the views on some implementations)
    • SiteEditHelper and SiteEditService are old and can be dropped
ProvidersThe Tridion/SDLWeb providers themselves are a nice to have, but the interface should be supported. I don't know of any custom implementations but it is conceivable.
Other stuff
  • TcmUri should be supported in the facade as a wrapper around whatever DXA will be using
  • DependencyMappings could be supported (this gives access to DI-managed objects from a non-managed context)
  • Resource management (labels) should be supported if it doesn't require too much hacking
  • Sitemap should be supported if it doesn't require too much hacking

...