PresentationModels

PresentationModels provides abstractions of model definition for various purposes. With presentation models you build UIs that are automatically generated, you can build various persistence mechanisms. Presentation models gives you the abstract of how model definition is created and how this definition is used.

Model definition

In heart of presentation models there is model definition. Model definition describes the object, or better to say 'type', is are building on. This definition consists of fields, that are defined in object/type, and metadata. Metadata is simple key value collection of items.

Field definition describes single item of model. This is has name and is of some type and, is in the model definition, contains collection of key-value items called metadata.

[Description("Edit person")]
public class PersonViewModel
{
    [Label("Name")]
    public string FirstName { get; set; }

    [Label("Surname")]
    public string LastName { get; set; }

    [ValueRange(0, 100)]
    [ToolTip("Set person age in range from 0 to 100.")]
    public int Age { get; set; }
}

The example class PersonViewModel shows typical model definition, which comes from .NET type and custom attributes. Building scaffolding or runtime UI generation on this is great, but presentation models goes to the next level. Not even lets abstract attributes from metadata, but also abstraction the whole source of model definition. One implementation of model definition, place in Neptuo.PresentationModels.TypeModels lets build model definition from class like PersonViewModel, the other, placed in Neptuo.PresentationModels.Serialization.Xml, lets you build models from XML documents. These XML based models but acts exactly the as models defined from .NET type. These is no need to change anything in the UI generation process.

With simple XML storage mechanism, you can build whole system without writing any line of code (so, if need only the CRUD UI without any business logic). This is very extreme scenario, but adding some simple parts of system that are customer specific and has 'no real business value' without programming can useful.

Getting and setting values

Right after definition model, you will need components, that creates and fills these model definition.

• For XML based models these is component that stores and loads values to and from XML document.
• For type based model, there is component that creates instance of PersonViewModel and fills it with values.

The great benefit here is that, because of the identity of the model definition, these components are interchangeable. So you can use XML document writer and reader for type based models (em, sure, you can't use type based value setters and getters for models, that doesn't have .NET type). And even better, you can combine those together, you can use XML document reader for creating model instance than using type based setter to store these values to .NET type like PersonViewModel. If you define component that stores and loads values to database, you can use it for both type based models and XML based models.

UI

Of course, main purpose of this library is to build automatically generated UIs. With the abstractions described above, you can build model-free and storage-free UIs that cares only for generating UI.

This process is, of course, target UI technology specified, so at this time, there on implementation of this in this repository. There is only the abstractions for defining UI structure.

In Neptuo.PresentationModels.UI there is the abstract concept of defining model views, which takes care of the design of the whole UI, and field views, which takes care of defining edit or read-only view for concrete field.

Model views typically takes collection of registered field views. Example editor table model view, which generates table with two columns, containing label and field editor, and one row for each field. This model view will simply iterate through collection of field definitions in passed model definition, for each field it will generate table row, table header containing label loaded from field metadata collection and table cell with editor view found in collection of field views.

These field views will be typically registered by field type, for example there will be field view for fields of type string that will generate TextBox, field view for fields of type bool that will generate CheckBox, etc. Field view defines two methods, one for getting value from view and the other for setting value to the view. Such field views can be reused by all model views.

Validators

Presentation models builds on Validators and provides base classes for single field validators. This way you can register validators based on field type and metadata.

Field validators are executed on type based model, there is no need for binding UI state to model, field views can take role of the model value source and validation can executed directly on values from UI.