Introduction

In the next following chapters we will try to dive deeper into different areas on MetaUI and this is the first topic. We touched a rule syntax in our previous chapter and now we will extend our skills.

Given a rule base Meta and a set of asserted values Context a list of matching rules can be computed (by matching their selectors against the values) and by successively (in rank / priority order) applying (merging) their property maps, a set of effective properties can be computed.

Each rule can be stated like this:

If selectors [__,__,...] match the current context values,
  then apply the properties [__,__,...].

These rules can come from a variety of sources:

Runtime introspection of Typescript classes

These rules declare the available properties (fields) along with their data types.

Example: "What are the fields in the User class?" In rules term:

  If selectors [class=User, declare=field]
      match the current context values,
  then apply the properties
      [field:name]
  
  
  If selectors [class=User, declare=field]
      match the current context values,
  then apply the properties
      [field:isAngularDeveloper]
            
  ...    

Since typescript (javascript) does not offer proper reflection support this is the reason for having getTypes() method.

​

Annotations on Typescript classes

Annotations can provide additional information not inferable from the class alone. Example: "Is the username required?" In rules term:

If selectors [class=User, field=userName] 
    match the current context values,
then apply the properties
    [trait:required]

​

Built-in rules

MetaUI includes a base set of rules (WidgetsRuels.oss) to describe, for instance, a mapping from field data type to UI component. Example: "If it's a Boolean (isAngularDeveloper) and we're editing, use the Checkbox component."

In rules term:

  If selectors [field=any, type=Date, editable=true]
      match the current context values,
  then apply the properties
      [component:DateFieldComponent]

​

Application provided rules

Applications may provide explicit rules via (User.oss). These are a convenient place to express presentation-oriented rules that really don't belong in (UI agnostic) domain classes.

Example: "The description field should appear after name field." In rules term:

  If selectors [class=User, field=description]
      match the current context values,
  then apply the properties
      [after:name]

In our example you could see OSS syntax similar to this (description goes after name):

zLeft => name => description;

or can be expressed as:

class=User {
 field=description {
    after: name;
 }
}

Other Sources of meta data

Many applications have other external sources of information about the application's domain classes. For instance, an application may have meta data comming from Rest API that provide additional information about classes and fields that should be taken into account when creating user interfaces (e.g. "is this field an owned to-many relationship?"). MetaUI provides generic hooks for integrating such sources of metadata (in fact, the metadata sources above integrate via these same hooks).

We'll go into more details for each type of rules, but for now let's take a look at context and properties...