| Feature | In DXA | DD4T .NET | DD4T Java | Comments |
|---|---|---|---|---|
| Features of the models | ||||
| Attribute-driven | Yes | Yes | Yes | Both attributes will be backwards compatible, but will choose one preferred one for future usage, try to consolidate/minimise use of attribute. Metadata could be separate property, but does not have to be |
| Support for strongly typed page models | Yes | Yes | Partial | |
| Support for page regions | Yes (in generic pages) | Yes (in custom page models) | No | Regions in DXA are created in the generic page to group CPs, in DD4T there are attributes to let you model this on the page. Regions should be in the Generic page model and have a pluggable region mapper. |
| Link and rich text resolving | Yes | Yes | Yes | Linking: Needs to be in the model and extendible. Mark properties as dynamic to decide on the spot. Rich Text: Needs to be in the model and extendible. DXA has a type which can contain html but also full entity models, should be an implementation of the rich text models |
| Multiple attributes on a property | Yes | No | Yes | Need to be clear on ordering and functional logic DXA and Java do it but maybe differently |
| Search in a tree structure (Flattening) | Yes | No | No | Good feature, but it must be made optional. Should only go into embedded fields and not linked components. Should this be enabled/disabled on a property basis, model basis or implementation basis? |
| Semantic vocabularies (eg schema.org) support | Yes | No | No | DXA currently requires that schema information published separately (publish settings page) - this is a bit of a pain so we should look at putting the semantics info in the DD4T JSON. |
| Multiple schemas per viewmodel | Yes | No | Yes | |
| Multiple viewmodels per schema | Yes | Yes | Yes | |
| Extensible attributes | No | Yes | No | Cleanup necessary. |
| Lazy properties? | No | No | No | Not needed in the framework - up to implementation - not really what MVC is about. DXA has ability to ignore individual properties, or all properties on the model by default which do not have attributes for mapping. |
| Implicit mappings | Yes | ? | No | Use existing conventions from DXA |
Self linking | Yes | ? | Bug | DXA uses a reserved "_self" 'field' name in the attributes for this |
| Map all properties to Dictionary | Yes | No | No | DXA Can map all schema fields to a single property of type dictionary/map - used for configuration models |
| Selecting expansion of component links on publishing | No | No | No | Quirijn's GUI extension to be able to define this on the schema - should be productized! This still respects the Link Level parameter as a max level to allow links to |
| Features of the model builder | ||||
| Bulk link resolving | No | No | No | Web8 architecture means a lot of http traffic can be generated as links are discovered and resolved when mapping models - this is a performance concern. CIL contains a bulk linking capability we we should use. |
| Uses reflection only once | No | Yes | Yes | DD4T reads all model information only once (using reflection), and uses it many times |
| Independent from MVC | Yes | Yes | Yes | It must be possible to use the ViewModels outside the context of MVC to facilitate testing etc |
| Injecting ExternalContentProviders | No | No | No | Controller/Model Builders are responsible for model enrichment. This feature should follow the same model as the current dd4t pattern of Controller > Factory > Provider. The factory then would be the place to process external content, whether or not that is in combination with extending data binding classes and / or view model attributes. |
| Single-step approach (from json to strongly typed object) | No | No | Yes | Nice to have - interesting to know what if any performance gain this gives. Needs to be extendible in the same way as you have modelbuilder pipeline. Needs to be EASY to create your own attributes. |
| Inject viewmodels using ModelBinder | No | Yes (in feature branch)Multiple ModelBinders to support various ViewModel implementations | No | This belongs in the MVC discussion and not the model mapping discussion |
| Support for older viewmodel architectures (DXA and DD4T) | No | No | No | Important to offer an upgrade path for all customers! No need to go into bespoke DD4T view model implementations pre 2.0 |
| Mapping Troubleshooting tool | No | No | No | Often a view developer will have the question "Why is this property not mapped?". They cannot be expected to debug the model mapper, so there should be some kind of tool where you can provide as input the raw data (DD4T JSON or even perhaps Tridion XML) and the model definition, and see how its mapped - visually if possible, but also with plenty of useful debug logging. |
Page Comparison
General
Content
Integrations