Rules

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.
A Rule defines a map of properties that should apply in the event that a set of Selectors are matched. 
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:
1
If selectors [__,__,...] match the current context values,
2
  then apply the properties [__,__,...].
Copied!
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:
1
  If selectors [class=User, declare=field]
2
      match the current context values,
3
  then apply the properties
4
      [field:name]
5
  
6
  
7
  If selectors [class=User, declare=field]
8
      match the current context values,
9
  then apply the properties
10
      [field:isAngularDeveloper]
11
            
12
  ...    
Copied!
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:
1
If selectors [class=User, field=userName] 
2
    match the current context values,
3
then apply the properties
4
    [trait:required]
Copied!
​
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:
1
  If selectors [field=any, type=Date, editable=true]
2
      match the current context values,
3
  then apply the properties
4
      [component:DateFieldComponent]
Copied!
​
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:
1
  If selectors [class=User, field=description]
2
      match the current context values,
3
  then apply the properties
4
      [after:name]
Copied!
In our example you could see OSS syntax similar to this  (description goes after name):
1
zLeft => name => description;
Copied!
or can be expressed as:
1
class=User {
2
 field=description {
3
    after: name;
4
 }
5
}
Copied!
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...

Extend your application

Next - Fundamentals

Context and Properties

Last modified 2yr ago

Copy link

Contents

Introduction

Runtime introspection of Typescript classes

Annotations on Typescript classes

Built-in rules

Application provided rules

Other Sources of meta data