The Model-View-Controller design pattern is a fundamental pattern employed in many software applications. This page aims to describe the specific details of the MVC pattern as used in the LxEngine architecture.
The model is composed of several varieties of data:
The source data.
Attributes are essentially "standard metadata" which will always accompany any source object. LxEngine stores only non-default attribute and uses grouping mechanisms to minimize the storage penalty of attribute data.
- Permission set
- Time stamping for create, modified, erased
- Reference count for shared or aliased objects
Metadata is a loose definition of attached, small, optional name associated with a data element stored in a JSON-like tree format.
Metadata always has a specific owner, allowing system-wide, per-user, per-view, or per-any-context metadata (each set of metadata can be assigned a arbitrary owner object, allowing specific metadata to be applied in virtually any context). As a consequence, the source and persistence of the metadata can vary. LxEngine attempts to mask the data source and persistence information from client code accessing the meta data in a read-only context, and only restrict such concerns to meta-data authoring code.
All metadata must be persisted along with source data to allow for a lossless reconstruction of the database.
Any data that is procedurally generated from the source data (e.g. a thumbnail for a large image) and cached to avoid regeneration. LxEngine, in the general case, automatically manages all regeneration and dependency tracking of such generated data - unless specifically indicated not to.
Temporary Data is similar to Generated Data, but uncached. Every request for this data will result in a re-computation of its value.
In general, the distinction between source, generated, and temporary data in LxEngine is intended to be as transparent to the caller as possible. However, there are instances where the client code may need to make the distinction.
Temporary data can always be upgrade to cached data by simply applying a flag to that data. Performance note: in the case of automatic caching, a generic caching algorithm is used by default with may not perform as well as specialized caching algorithm which is aware of the data payload and usage characteristics.
A view of the data along with a set of parameters. Templates always provide a full set of default values for all parameters. Parameter specification is required only for customization of the view.
A single data element may used different view templates in different contexts; therefore, customizations to a template are not discarded when a different template is applied to the source data.
A view customization is considered an application setting, not database metadata. The database is considered to be entirely within the model. Customization data for an application should be exported separately and distinctly from the root database.
Data views of particular data type usually come with a set of options or parameters to define the specific rendering of that view. Any such parameter which is set to a non-default value is considered a "customization". Parameters that are common across multiple different templates are referred to as standard template parameters. Thus, any standard customization will apply to view of the data regardless of which template is being used.
Template customizations are non-default parameters which are applied only to a specific template. This may be done for one of two reasons:
- The parameter is question is non-standard and applies only to this template
- The parameter is standard, but the customization has been explicitly denoted as applying only in the case of a specific template
With a standard customization and template customization are applied to the same named parameter, then the template customization has precedence.
TODO: To be updated