The LxEngine application is composed of the following major concepts:
Persisted data is stored by the DataSource. At run-time, loaded data is organized into a Document which uses a Space as the high-level organizational structure. Individual Objects in the document are placed into a hierarchy of Elements within the Space.
There is one and exactly one instance of an Engine object in an LxEngine application. This is the root Singleton from which all aspects of the LxEngine functionality ultimately can be reached.
Provides a concise, perforce-like interface for serializing in and out named objects from file system or network source. It allows objects to be forked, locked, updated, reverted, tagged, etc.
- Abstraction of the data source (file system, zip file, local database, network based, procedurally generated objects)
- Abstraction of the data format (JSON, XML, binary, file formats and codecs, etc.)
- Optional object metadata tracking (enforce a consistent interface across the data set)
- Optional object permissions enforcement (ownership, sharing, locking, etc.)
- Optional revision history (version control, forking, journal, etc.)
- Optional transaction-based collaboration (change sets)
- Optional indexing, caching, and paging
The engine is aware of one or more data sources.
Represents a collection of runtime objects created from one or more data source objects.
A Document can be thought of a unified whole, whereas an Element is an organizational structure within that whole (which likely does not make full sense in isolation) and an Object is a concrete detail within the Document. The Elements within the Document can arranged into a particular kind of Space, depending on the most appropriate organizational strategy.
Note: Documents support embedding of other documents allowing arbitrarily complex data models.
A document is composed of 1 or more Spaces. The space defines the conceptual layout of the elements contained in the document: it defines the notion of adjacency between elements as well as the size of elements. Each Space in the Document has one root element.
Example Spaces would be an infinite 3D space, a bounded 3D space, an infinite 2D space, a paginated 2D space, a 1D overlapping timeline-based space, or a purely conceptual space (i.e. no real-world spatial analogy).
A logical portion of a document representing one or more runtime objects. Elements may be nested into a heirachy. As general organizational structure, only objects in the same element can directly interact with each other and an element can only influence those objects within it or within one of its child elements.
Elements use a HTML DOM-like structure and allow for a CSS-like attribute inheritance between elements. Document Views can utilize this structure to stylize and transform the underlying data for a particular view.
A run-time object in the LxEngine system. This is a generic, reference-counted object with interfaces to supports all basic LxEngine functionality. All persistent objects in the Document should use derive from this class. Transient (non-persistent) objects do not need to incur the slight overhead.
Note: since all persistent objects are encouraged to derive from this interface, the internal representation is careful to internally optimize for performance and size based on the actual use of the object in order to eliminate as much undue overhead as is possible.