Web UI Design: Entity Masters

Entity Masters

Everything in TG is modelled by means of fractal objects -- an entity and its companion. This includes entities that model both nouns and verbs in the target domain. So, objects like Work Activity and Purchase Order, but also processes like Purchase Order Authorisation and Issuing of Part to a Work Order are modelled as entities. Each entity may have its own Entity Master through which it gets created and modified. Basically, entity masters represent the main way to organise a UI for users to modify the state of an information system. Therefore, it is very important to understand all of the building blocks for constructing Entity Masters and the ways to interact between them at the client side, and also them and corresponding web resources.

Kind of Entity Masters

There are two kinds of Entity Master, each operating in their well defined and very specific way.

Simple Entity Master

An entity master that represents an entity without dependent entities or a dependent entity itself. For example, a majority of table code entities have no dependent entities and can be conveniently represented using a Simple Entity Master (e.g. entity Address or Rego).

At the same time simple dependent entities can also be represented using Simple Entity Masters. For example, WaDirectCharge is an entity that attains its meaning strictly in the context of some WorkActivity, has no dependent entities and can be conveniently represented on a Simple Entity Master. However, in this case the master should carry the information about the master entity. In case of this example, a specific work activity. This information is critical for both validation and persistence of dependent entities.

Simple Entity Masters could be displayed either in a modal or normal way. The modal way usually has very specific purpose of either providing a quick look at some entity, create a trivial entity ad-hoc or provide data for some action. A Simple Entity Master in a dialog form should only have two buttons -- CANCEL and OK -- and should always be displayed in the EDIT state. The OK button should correspond to action Save with appropriately defined POST-SAVE action. The CANCEL button, should simply close the dialog and fire the POST-CANCEL event.

Compound Entity Master