...
| Reference | Priority | Description |
|---|---|---|
| Model-1 | Must have | The ModelBinder can bind Entity (Component Presentation) and Page Models from DD4T JSON |
| Model-2 | Must have | The logic to determine the model Type from the source data should be extensible via an IModelTypeResolver |
| Model-3 | Must have | There should be default IModelTypeResolvers to support existing DXA and DD4T logic - this will support the n→m mapping of schemas/component presentations to view models. |
| Model-4 | Nice to have | The ModelBinder does not need to deserialize the source JSON into IPage or IComponentPresentation models before binding the view model |
| Model-5 | Must have | The ModelBinder should be able to operate in isolation and thus independent from web application context and content provider. This also means there should be no dependencies on MVC classes or concepts. |
| Model-6 | Nice to have | The ModelBinder has a test tool that can be used to test model binding without having to run the full Tridion and web application stack. This tool would take a set of DD4T JSON strings (for example a test set generated/copied from the CMS) and a library of model classes and show detailed binding logging and output checking which model properties are bound and to what source elements. |
| Region-1 | Must have | The ModelBinder can resolve regions from the set of CPs on the page |
| Region-2 | Must have | The logic for resolving regions is extensible using a IPageRegionResolver. The default behaviour is to resolve everything into a single region |
| Region-3 | Must have | A IPageRegionResolver which implements the DXA Region resolving logic will be provided |
| Link-1 | Must have | The ModelBinder can resolve fields which are component links into URLs |
| Link-2 | Must have | The logic for resolving links is extensible using an ILinkResolver |
| Link-3 | Must have | Model properties can be marked as 'dynamic' to prevent the link being resolved when the model is built |
| Link-4 | Must have | It should be possible to bind a property to a resolved link to the source item (page or component) |
| Link-5 | Nice to have | Link resolving when binding a model can be done in bulk (once per model). Web8 architecture means that individual link resolving can result in a lot of http traffic. CIL contains a bulk linking facility which can be used to minimise this. |
| RTF-1 | Must have | The ModelBinder can resolve Rich Text fields (resolving links and binaries) |
| RTF-2 | Must have | The logic for resolving rich text is extensible using an IRichTextResolver |
| RTF-3 | Must have | An implementation of the IRichTextResolver which implements the DXA Rich text resolving will be provided (splitting the RTF into a list of entities/html blocks) |
| Prop-1 | Must have | Multiple fields can be bound to the same model property. Attributes will be processed top-down until a source field is found to bind to the property |
| Prop-2 | Must have | A model property can be bound to a field within embedded schema(s) to enable 'Flatter' view models to be defined whose structure is not forced to correspond 1-1 to the source schema. This functionality will not extend to linked components however. |
| Prop-3 | Must have | Flattening should be optional and enabled on property, model and/or ModelBinder level |
| Prop-4 | Must have | A default, convention based binding should be implemented to allow for models without annotations/attributes to be used (map property names to schema field names using the DXA convention (PascalCase property to camelCase fieldname, drop a trailing s from enumerable properties (=multivalue fields) List<Paragraph> Paragraphs → paragraph field name) |
| Prop-5 | Must have | Model properties can be marked as ignored for binding purposes, and indeed at model level set that by default all properties without binding attributes are ignored. This allows for models whose data primarily comes from other sources to be efficiently bound. |
| Prop-6 | Must have | Model properties can be bound not just to field data, but also to system data (like Page/Component/Template Title, Id etc. |
| Prop-7 | Must have | Model properties can be bound to template metadata fields |
| Prop-8 | Must have | It should be possible to map all source fields to a single property of Dictionary/Map type (DXA has this for configuration models) |
| Prop-9 | Must have | Extensible attributes (support what DD4T has) |
| Prop-10 | Nice to have | Model properties can be bound to arbitrary (ie not necessarily DD4T) JSON in the source data. This will allow custom JSON data to be injected into the DD4T JSON by templates which integrate with other content providers. |
Interfaces
The following gives a draft of the interfaces required related to Model Binding. For convenience C# syntax is used.
| Code Block | ||
|---|---|---|
| ||
public interface IModelBinder
{
//We know upfront the type we want to bind to (IContextData is some kind of helper interface for processing the raw JSON)
T BindPage<T>(IContextData data) where T: IPage;
//Allow the type to bind to be determined by the context (eg page template) (note this is not the DD4T IPage)
IPage BindPage(IContextData data);
//We know upfront the type we want to bind to
T BindEntity<T>(IContextData data) where T: IEntity;
//Allow the type to be determined by the context (eg component template/schema)
IEntity BindEntity(IContextData data);
} |
Default Implementations
The following gives a draft of the default implementations; base classes which have virtual methods can be extended to alter model binding behaviour
| Code Block | ||
|---|---|---|
| ||
public class DefaultModelBinder : IModelBinder
{
/* -- IModelBinder implementation not added --*/
//Can be overridden to apply specific property binding implementation
protected virtual void BindProperty(object Model, PropertyDescriptor propertyDescriptor, IContextData contextData);
} |
Attributes/Annotations
The following gives a draft of all the supported attributes/annotations related to Model Binding:
TODO