Web UI: Actions

This page delves more into the Action API and the interaction of actions with various views such as Entity Masters and Centres. A central subject of this discussion is the execution context for actions: how does it get determined and provided for the actions to run. Another very important part of the discussion pertains to a mechanism that is responsible for interaction between the callee of an action and the results of action execution.

1. Action types
2. Actions with View
3. Actions without View
4. Action Context
5. Action Events
6. Callbacks

Action types

The following list of different types of actions were introduced in the Swing UI and need to have Web UI correspondence. Any new types of actions that might appear during the development of various applications should be added to this list.

1. Entity actions on Entity Masters.

   1.1. Simple Master or Main on Compound Master (always in relation to master entity).

   • Standard actions New, Edit, Save, Cancel, Refresh.

   • Custom actions (e.g. Authorise)

   1.2. One-2-one view on Compound Master (always in relation to a dependant entity).

   • Standard actions Edit, Save, Cancel, Refresh.

   • Custom actions (e.g. Authorise)

   1.2. One-2-many view as a custom Entity Centre on Compound Master.

   • Standard actions Refresh and Pagination.

   • Custom actions (always in relation to one or multiple selected dependent entities)

2. Property actions on Entity Masters.

   2.1. Ad-hoc creation of an entity with automatic assignment of the created value back to the master entity property upon successful saving the that new entity value (enabled state EDIT).

   2.2. Show details of a calculated property. In most cases this would result in a custom Entity Centre being presented on as separate view with Pagination and Refresh actions. Enabled state is VIEW.

3. Entity Actions on Entity Centres.

   3.1. Standard actions Refresh and Pagination.

   3.2. Custom actions for one or more selected entities in EGI.

   3.3. Standard actions embedded into an entity representation on EGI such as Edit and Delete.

   3.4. Custom actions embedded into an entity representation on EGI such as Authorise, Receive etc.

4. Property actions on Entity Centre.

   4.1. The Tap action on ordinary property should open up a corresponding Entity Master as per current Swing UI rules.

   4.2. The Tap action on a calculated property that represents aggregation should open a details view, which would be a custom Entity Centre in most cases.

Actions with View

A high level activity diagram of an action with view is presented below. It describes what happens when an action gets triggered, which could be a result of some user activity such as button tap or a programmatic call.

The first thing that happens is the execution of a pre-action if it was specified. Pre-action might be represented by some confirmation dialog. Depending on the nature of the confirmation and user's decision, the actual action execution might be skipped all together. However, it could also be something more trivial such as enabling a blocking pane or disabling some UI elements, which does not effect the action execution process.

Next up is the step where two things should happen asynchronously:

• A specific to the functional entity behind the action (action entity) view (UI) gets obtained.

  This would initially result in a GET request to a corresponding UI resource (e.g. EntityMasterResource). However, subsequently an already loaded web-component that represents that UI would be used instead of making a server request.

• In parallel to obtaining a view, a separate GET request goes to a corresponding functional entity web-resources, which returns a new functional entity. An appropriate EntityProducer could be associated with a functional entity to provide server-side initialisation.

  It is important to understand that the process of getting an instance of a functional entity does not have to be server driven. Where applicable it could be created and initialised purely at the client side. This, however, would require some support at the Java API level to clearly specify the rules for such JavaScrip driven entity creation.

  Once an entity is obtained, it needs to be initialised with an execution context. The execution context is known only at the client side. Therefore, any initialisation after obtaining an entity instance can only be done at the client side. There are many possible ways to interpret the process of initialisation. However, a uniform and action type driven approach is required. It is proposed to reduce the initialisation step to the assignment of the execution context. The detailed discussion of context is done further below. For now, we can consider that an execution context is a master entity from whose Entity Master the action was triggered. This means that the functional entity should have property context of the type matching the type of master entity.

  In some cases, there would no need to initialise the returned functional entity.

Once the functional entity is initialised and its view loaded, the entity can be associated with the view by means of binding. This is where we can consider the action completed and ready to show the constructed view. However, just before doing so there is a need to perform a post-action if it was specified. The main role of the post-action in this case is to register callback functions with the constructed view. Callbacks are covered in further sections, but completeness of this discussion, we should think of callbacks as a way to do something to the view where the action was triggered as a result of some events happening on the action view. This means that callbacks can only be registered to events that are produced by the action view.

Actions without View

A large number of actions neither require a user input nor do they need to present the result of their execution on a separate view. This is the simplest for the UI interaction standpoint type of actions. This means that such actions can be executed purely on the server side, and most likely result in some server side computation (including persistent state update). At the most it is envisaged that such actions would only require an update to the current view where the action was triggered from, such as refreshing of the master entity on an Entity Master as a post-action activity.

The actual refreshing could be achieved in two possible ways (to be executed as part of the post-action). One way is by requesting a refresh from an Entity Master where the action was triggered. Another way to simply rebind an entity to that Entity Master in case an updated revision was provided back to the client as the result of the action execution.

Action Context

Action Events

Callbacks