Projects:Parameter Windows Phase 3/Functional Specification
Contents |
Introduction
This phase of Parameter Windows project aims to cover all the functional gaps detected in order to be able to reimplement AP/AR windows (Add Payment) as Parameter Windows.
Missing Features
Below the list of features that have been detected as requirement to support APRM windows refactor.
Parameter Position in Row
Parameter Windows are rendered in a 4 column layout form. By default each parameter is positioned at the right of the previous one.
This capability allows to force the column position of a given parameter.
JS Pre Actions
When button to execute process is clicked, it will be possible to define a JavaScript function to be executed before invoking the backend Handler.
This function (manually coded), can:
- Perform validations on the parameters, being possible to prevent execution in case these validations are not satisfied.
- Request for additional info to complete the parameter values.
Actions executed by this function can be asynchronous (requiring backend calls or user interaction). To support it the function will receive as parameter a callback in charge of invoking the Handler, this function is responsible of calling it in case the process should be finally executed.
Parameter Callouts
Implemented as JavaScript functions, in the same way field's On Change Function.
These callouts should receive as parameter the whole parameter window context, so they can modify other parameters including values in grid parameters.
Grid Callouts
(Check current status)
Fields in grid parameters can execute callouts, these callouts, in the same way the ones for regular parameters, have access to the param window context so they can modify regular parameter values.
Grid Display/Read Only logic
Treating grid as a regular parameter it should support Display and Read Only Logic.
Multiple Grid Parameters
Currently, Parameter Windows allow only one parameter defined as a grid and it is always placed at the bottom of the window.
Grid parameters should be treated as regular ones:
- Allowing to define multiple grid parameters
- Allowing to add parameters after the grid ones
Backwards compatibility considerations:
- Currently grid information is always sent to backed with a fixed name. This requires to be changed to be sent with the name of the grid parameter, but for those windows having one grid, it is required to be sent also in old format not to break API making existent Pick and Execute windows not to work anymore.
- Currently sequence number for grid paramters is not taken into account as they are always placed at the bottom. Now it will be taken into account, this can make change current layouts of windows combining grid and regular parameters.
Subordinated Default Values
Currently default values are evaluated without taking into account dependencies.
Implicit Filter in Grid
In the same way selectors do, allow to define implicit filters in grid to be displayed as filter values, so user knows how it is filtered and can remove (some of) them.
Grid Field Validations
Overwrite P&E field properties
Before opening the popup an ActionHandler call is done sending context info which can define specific settings per field (visible, editable, sortable, filterable). It affects fields in grid and params.