5.8.9.1.Main workflows and participants
Introduction
The important concepts used in the FlexiCore dynamic User Interface are:
- When the backend and frontend technologies are related, that is, 'knowledge of each other' better implementation can be achieved.
- Many Developers User Interface tasks are repeated and similar.
- Changes in a system are best implemented in one step.
- Drawing from the concept of 'application generators', people involved in a system lifetime include knowledgeable users capable of creating objects for other users. Under this paradigm, a superuser replaces the front-end developer.
Actors ( people related to the system)
Backend developer
The backend developer is responsible for creating new services and domain models at the back-end using FlexiCore plugins. The back-end developer decides on the API endpoints added, the Request and Response objects, and domain model additions.
Front-End Developer, hardly needed.
The front-end developer is responsible for supporting the dynamic UI services and widgets available in the proper SDK (Angular or Dart Flutter), this is done once and no changes are required when the backend exposes new features.
Superuser
The superuser is responsible for creating new objects such as Gridpresets, Trees, Dashboard Preset, Rules, etc. This is carried out using point and click without programming, it simply requires better knowledge of the system features.
Once a new service exposes new APIs on the back-end, the superuser can use them on the user interface without any intervention from the front-end developer side. This is true even when new APIs are available. So, for example, when a new data source (see below) becomes available the superuser can create a new Datagrid showing a new type of data sets so users can view the data and apply sorting and filtering based on the superuser Datagrid (gridpreset) design.
User
Users interact with the system without knowing how user interface widgets were created, by the user interface developer or by a superuser.
Workflows
By the User-Interface Developer
implement support for dynamic UI widgets use, creation, and editing.
The user interface (front-end developer) implements dynamic user interfaces to be used by all users and superusers. This can be carried out by either using the available back-end APIS available for supporting the lifecycle of dynamic UI classes or by using the lately developed client-side SDK component and services for saving a great deal of time in the implementation of a dynamic user interface support.
Not all implementation must include the editing side used by superusers, for example, the definition of a grid preset can be implemented on the browser only (Angular, Flutter). On mobile devices, implementation can include grid preset viewing and filtering only. This is a design decision.
By the back-end developer
The back-end developer doesn't have to change the standard implementation of services and models. The only additional, optional work is adding some metadata to methods (endpoints) and fields so dynamic user interface implementors can rely on them for more accurate implementation.
For example, if a method parameter field is defined as int and has max and min values, the user interface implementation can use a slide widget for such fields, likewise, the 'possible values' field in a parameter definition is of a type String and has a set of possible values, a drop-down can be implemented.
By Superusers
Superusers/administrators are responsible for the creation of usable instances based on the backend implementation.
Subtask: Define a data source (a Dynamic Execution using listAll method)
Superusers define a data source by selecting an Invoker from a list or by searching for the handling type an invoker supports. When a data source is defined, superusers can add optional filtering. This is similar in concept to views in SQL database.
Once a data source is defined, it can be reused for the creation of Trees, Grid Presets, Rules, and Dashboards. The definition of a datasource is saved in the database.
notes:
- The term datasource is used here for brevity. The backend creates a Dynamic Execution instance in the database for all InvokerMethods+Filtering saved in the database. When looking for datasource, an easy to use creation user interface should hide methods that are not listAll/
- Data sources are created and edited using the frontend user interface. Wizzdi provides client-side SDK and Angular services to make the implementation of data sources' creations a straightforward task, done once for each front-end browser application (by a front end developer)
- A sample application for datasources definition is available.
Subtask: create or edit a Datagrid from a Datasource (DynamicExecution)
Superusers can define datagrids along with these options:
- select a datasource from the available datasources (DynamicExecutions)
- select the visible fields from the typical response (a JSON object), associate the fields with columns
- define columns' width allocation
- define additional filters (reducing dataset size as is governed by the original filter the datasource may have).
- define run-time filters users will be able to use when viewing data.
- define access permissions to Grid Presets
- Link subgrids to a grid.
- Grids can be used from a selected row on a parent grid, In this case, filtering is narrows to reflect the selected row. For example,
- the parent grid shows customers.
- sub-grids show
- sales
- support calls
- orders
- the sub-grids are always filtered by customer id.
- Grids can be used from a selected row on a parent grid, In this case, filtering is narrows to reflect the selected row. For example,
notes:
- Datagrid presets (called Gridpreset) are saved to the database.
- As all other objects are, Datagrid Presets are subjected to the FlexiCore access control system.
Subtask: create or edit Hierarchical view from multiple datasources.
Subtask: create or edit a Dashboard preset from multiple datasources.
Subtask: create or edit Rules multiple datasources and triggers.
Subtask: Associate available user interface buttons with specific dynamic objects.
By Users
Users can view the available dynamic objects created for them that they are allowed to see and use, such dynamic objects can be available from a list per type, for example, a list of grid presets.
When a dynamic object is associated with a user interface element, then users can view the data when these elements interact with.