DataProvider
DataProviders are objects used to fetch data from the Kyub API/Database and provide it to the ElementBrowser component in a unified manner. They are all defined in the src/views/components/elementBrowser directory.
Inheritance
All DataProvider objects need to either directly implement the IElementBrowserDataProvider interface or extend a class implementing this interface. The inheritance structure is shown in the graph below (rendered with mermaid, works on GitLab or here).
graph TB
IElementBrowserDataProvider --> BaseDataProvider (abstract)
subgraph " "
subgraph " "
ListBasedDataProvider (abstract)
ListBasedDataProvider (abstract)-->GenericListDataProvider
ListBasedDataProvider (abstract)-->GroupMemberDataProvider
ListBasedDataProvider (abstract)-->MaintenanceDataProvider
ListBasedDataProvider (abstract)-->MainenanceTypesDataProvider
ListBasedDataProvider (abstract)-->WorkshopUserDataProvider
end
BaseDataProvider (abstract)-->ListByIDDataProvider
BaseDataProvider (abstract)-->ListBasedDataProvider
BaseDataProvider (abstract)-->SearchDataProvider
end
IElementBrowserDataProvider-->JobDataProvider
Dynamic Context Menu
All DataProvider extending the BaseDataProvider allow for a dynamic context menu to be defined. This context menu will be shown on each element card for the data provided to the ElementBrowser. Actions in the menu will perform a provided callback function on click.
The BaseDataProvider maintains an array of context actions which will contain action-defining objects. New actions may be added/defined by calling the function addContextAction and providing the configuration object to it. Each of these objects needs to provide the following:
* handler - a callback function performing the action that should happen on click (e.g. removing the affected element from your group).
* displayText - the string that will be shown in the context menu
Additionally, there are two more keys that may be included in the configuration object:
* style - one of "normal", "warn" and "danger". This will lead the context menu entry to have a different style (e.g. delete actions should always be of style "danger")
* requiredPermissions - permissions required to perform the action as strings. The strings given here must have matching keys in the permissions object of the BaseDataProvider (explained below) or the addedPermissions provided to the _generateContextMenu function (explained below). If not all of the permissions are true at time of rendering, the action will not be added to the context menu.
The BaseDataProvider also maintains an object of permissions, where the key is the permission name (a string) and the value is a boolean indicating whether a permission is given or not.
Per default, the permission "canEdit" exists and is set to false. This permission needs to be set to be true in oder for the context menu to be created in the first place. Additional permissions can be set by calling the setPermission function, which you will have to provide the permission name (i.e. the key) and its value to.
Finally, a DataProvider extending the BaseDataProvider or any of its (grand-)children will be required to call the _generateContextMenu function for each of its elements. This is done after the data has been collected and converted into objects adhering to the IElementCardData interface.
Direct children of the BaseDataProvider are also required to implement the _elementToActionForwarder function (grandchildren and more are still encouraged to consider this). The purpose of this function is to take an object referencing the displayed data (i.e. adhering to theIElementCardData or similar interface), identifying the corresponding object in the original (database) data and preparing the input for the action handler callback functions (of type HandlerArguments). Examples for this function can be found in the existing DataProviders, however it comes down to either a direct comparison (in these cases it is expected that the card data and original data are the same) or a comparison checking ids and element types.