Generic Table View Component

1. Averos Dynamic Table Component

1.1. Description

Part of the search input use case, averos-dynamic-table introduces a higher level grid implementation that leverage angular material table in addition to a couple of built-in enhancements that meets some basic additional usecases such as Export Data, column rearrangement, data reload, Create Record, View Record, Edit Record and Delete Record use cases.
averos-dynamic-table fits perfectly to any composite use case that include multiple data management.
The component’s enhanced styling comes to enrich the user experience with highly responsive design and rich capabilities

Below is the component’s UI responsive layout :

Averos Generic Table - Responsive Layout

The component comes with a customizable customizable data search filter which could either be visible or hidden using the boolean component parameter showFilterComponent.

By default, Averos generic Table implements header actions and row actions. Those actions could either be visible of hidden using the component parameter showRowActions.

1.2. Header Actions

Default header actions are:

create : uses the component action parameter addObject
reload : uses the component action parameter reloadTable
export : exports the current search result to csv or excel

1.3. Row Actions

Default row actions are:

view : uses the component action parameter viewObject
edit : uses the component action parameter editObject
delete : uses the component action parameter deleteObject

🚩 Action parameters are bound to business functions and that hold the related action logic. The atomic component averos-dynamic-table exposes these actions as specific events. Those action events will trigger further business logics that are meant to be handled in a top layer use case component.

1.4. Custom Row Actions

Apart from the default actions, averos-dynamic-table atomic component provides a way to embed different types of custom row actions. These custom row actions could be created using the composite parameter customRowActions depicted by a set of elements of type RowAction.
Each custom row action is bound to a RowAction instance.

Below is the RowAction class definition.

Averos Generic Table - Row Actions Class — Averos Generic Table - Row Action Class

A custom averos table row action is defined using the following attributes:

actionID
actionTranslationID
isActive

Custom row actions could dynamically be displayed depending on customizable criteria using the attribute isActive of type function. isActive defines a logic that tells whether the element represented by a table row is subject to the action or not.
If the element is subject to the action then the custom action will be available to the user, otherwise it will not.

Below is an example of three custom row actions (excerpt from wibuild application).

Averos Generic Table - Custom Row Actions

Averos Generic Table - Custom Row Actions (Responsive)

In order to perform its business capability, a custom row action relies on the event action executeCustomRowAction. The latter, should be implemented in the top component layer and should support all existing custom actions based on the appropriate event of type RowActionMetaData.

Below is the RowActionMetaData class:

Here is an example of executeCustomAction implementation that support a custom action named Download.(Excerpt from wibuild application)

executeCustomAction(rowActionMetaData: RowActionMetaData){
    switch(rowActionMetaData.rowActionID){
      case 'Download':
        this.downloadApplication((rowActionMetaData.rowData as MyAverosApplication).applicationID);
        break;
      default:
        break; 
    }
  }

Multiple actions could be created and handled in the same method on a case-by-case basis.

🔖 Please note that all custom action related to averos dynamic table are displayed on each row, in the last column (i.e. the sticky column).
Besides, all custom actions components layout remains responsive as well, just the same as default row actions.

2. Component’s usage example

<averos-dynamic-table [trackByField]="trackByField"
                      [data]="data"
                      [showRowActions]="showRowActions"
                      [showCustomRowActions]="showCustomRowActions"
                      [customRowActions]="customRowActions"
                      [showFilterComponent]="showFilterComponent"
                      [filterComponentLabel]="filterComponentLabel"
                      [filterComponentLabelTranslationID]="filterComponentLabelTranslationID"
                      [filterKey]="filterKey"
                      [viewLayout]="viewLayout"
                      (viewObject)="view($event)"
                      (viewCompositeObject)="viewCompObject($event)"
                      (executeCustomRowAction)="executeCustomAction($event)"
                      (editObject)="edit($event)"
                      (deleteObject)="delete($event)"
                      (addObject)="add($event)"
                      (reloadTable)="reloadData($event)"
                      (search)="searchData($event)">
</averos-dynamic-table>

🚩 A set of methods could be implemented and bound to related events in order to add additional actions to the dynamic table:

viewObject: view a simple record

viewCompositeObject: view a composite relation (either OneToOne or OneToMany)

editObject: edit a record

addObject: add a record

deleteObject: delete a record

reloadTable: reload data

search: search data

🚩Since it is meant to handle an array of object, averos-dynamic-table component layout relies on either tableUCViewLayout or selectableInputTableUCViewLayout configurations as these two EntityViewLayout are meant to manage multiple objects.
This means that any entity that is bound to be displayed within an averos grid should set up a tableUCViewLayout or a selectableInputTableUCViewLayout configuration beforehand, either by means of a json configuration file or by adding a view layout configuration to the entity class, so that the grid component could be displayed correctly.
If an averos grid was requested but there was not any related tableUCViewLayout or selectableInputTableUCViewLayout configuration available, the component will throw an exception and the view will not be rendered.
Table header Rows are ordered based on the field order (FieldViewLayout.order) if the latter exists and is not null or is undefined.
Otherwise the natural ordering will be performed based on the field evaluated text expression.

Twitter Facebook LinkedIn