IBM Software Group  |  Lotus software
IBM  Lotus Forms
© 2007 IBM Corporation
Example: Model Property Broker
§Model may annotate data with useful properties, e.g. data type, constraints, patterns, validity, relevance, and mutation locks
§Model properties consumable by controllers and views
§Model properties mutated by procedural or declarative means
A good example of a common capability that could be built into the backplane, aside from the basic data object already described, is a model property broker.
As depicted, the model property broker surrounds the data, but it could attach in some other way.  It’s purpose is to annotate the data with useful properties.
A good example property is data validity on a datum by datum basis.  The validity can be based on an assigned schema datatype or pattern, or by some boolean formula that decides validity based on comparison to other data.  An example is ordering an old journal paper photocopy from an interlibrary loan service.  You specify the lower page number then the upper page number, and the constraint would indicate that the upper page number must be at least as great as the lower page number.
Another useful property is here called relevance, which seeks to indicate data that may sometimes be needed in a process but is perhaps not needed currently due to some conditions in the data provided so far.  For example, while applying for some kind of insurance policy or perhaps a tax refund, a given birthdate specified by the user might make portions of the data corresponding to being a minor or a senior citizen non-relevant to that user.
Yet another model property could be a mutation lock that prevents the associated data node from being mutated by a data object binding, or perhaps even by script commands that access the data object.  This is a version of ‘readonly’ directly for the data.
The model properties are inherently useful to different kinds of components.  For example, a view component that binds to non-relevant data could become unavailable to the presentation layer in some way and also deactivate event handlers for which it is the target.  A submission object may be configured to omit non-relevant data from the data it serializes for submission.
Finally, note that the maintenance and update of these properties could be regarded as a separate module, thus avoiding the whole issue of whether they are better managed by declarative expressions or procedural scripts invoked by event handlers.  The real answer is that they will be handled by whatever means that the application architect finds easiest to develop and maintain, and the issue of the utility of a model property broker is orthogonal to the issue of how they are maintained.