-
Notifications
You must be signed in to change notification settings - Fork 7
Web UI Design: 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.
There are two kinds of Entity Master, each operating in their well defined and very specific way.
Simple Entity Masters should be used to represent 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 as a Simple Entity Master. However, in this case the master should carry the information about a corresponding master entity (Work Activity
in this case). 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 a very specific purpose of either providing a quick preview of some entity or create a simple entity ad-hoc, or provide data for some action (and thus execute that 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 should be used to represent complex entities -- those that have a master role in one-2-one and one-2-many associations. Such masters are equipped with a menu that provides a way to navigate between their compound parts. The depth of the menu should be limited to one, consisting of the top level and the level below at the maximum. This constraint will ensure simplicity of the navigation system from the user perspective under assumption that it should always be possible to arrange Entity Master menu in this way.
The way to represent one-2-one association should be as per Swing UI, where a separate menu entry is associated with panel with located on it editors for properties of the dependent entity. It can be thought of as an embedded simple master, provisioning for standard and custom actions.
The one-2-many association should be represented by a Custom Entity Centre with ability to edit and add new dependent entity instances by invoking a corresponding Simple Entity Master in a dialog mode.
All actions on Entity Masters regardless of whether this is a Simple or a Compound Master belong to two categories:
-
Entity related -- the semantics of such actions pertains to an entity as a whole; for example, action Authorise semantically is related to an entity, even though the underlying change really just updates its single property
status
; actions in this category should only be enabled when Entity Master is in stateVIEW
. This is required to make sure that all entity changes are persisted. Often, the post-action of such actions should lead to invocation of a standard actionRefresh
to make sure that the latest data is displayed to the user. -
Property related -- the semantics of such actions pertains to a single property modification; such actions should only be enabled when Entity Master is in EDIT state; as good example of such action is ad-hoc creation of new value to be assigned to a specific property; there should always be a visual cue that associates action with a specific property such as a button that is located next to a property editor.
It is proposed that a single property related action should be represented by using icon buttons, located immediately to the right of a property editor. In case of Polymer this should be a paper-icon-button.
There could be a situation where more than one property action is required. In such cases a paper-menu-button should be used, which basically looks like a paper-icon-button
, but invokes a dropdown menu with a selection of actions to perform.
Action API should provide a way to specify upon what Entity Master state a property action becomes enabled. From the layout perspective, the action icon button should considered as an extension of the widget (e.g. an input) that represents a corresponding property. This basically means that when calculating the width for placing a property editor, the icon button width should also be taken into account as depicted on the image below.
Per aspera ad astra
- Web UI Design and Web API
- Safe Communication and User Authentication
- Gitworkflow
- JavaScript: Testing with Maven
- Java Application Profiling
-
TG Development Guidelines
- TLS and HAProxy for development
- TG Development Checklist
- Entities and their validation
- Entity Properties
- Entity Type Enhancement
- EQL
- Tooltip How To
- All about Matchers
- Streaming data
- Synthetic entities
- Activatable entities
- Jasper Reports
- Opening Compound Master from another Compound Master
- Window management test plan
- Multi Time Zone Environment
- GraphQL Web API
- Guice
- Maven
- Full Text Search
- Deployment recipes
- Application Configuration
- JRebel Installation and Integration
- Compile-time mechanisms