View source | View content page | Page history | Printable version   

Projects:Parameter Windows





Parameter Windows are defined in the Application Dictionary (AD) and used for generating user interface, usually a pop-up window, to ask the user the values of process parameters.

Sample of a parameter window generated by WAD based on 2.50 parameter implementation.


Feature overview

In the current implementation, parameters are associated only to a Process or Report. The definition of the Processes and Reports is made in the same table AD_Process table, and this definition is bloated with too many columns (flags at user level) that is hard to maintain and understand.

The goal of this project is to provide a new infrastructure to define Processes and Reports and the Parameters associated to them. The new infrastructure will enable to define parameter for any Entity that requires it.

Users & use cases


Functional specification

Must have

Nice to have

Technical specification

Parameter Windows will make use and extend infrastructure created for Pick and Execute pattern (OBUIAPP_Process and OBUIAPP_Parameter tables). This means a new infrastructure for process is provided, but 2.50 style one will still be kept and old processes will not be automatically migrated.

Bulbgraph.png   NOTE: If you the user makes use of the 2.50 implementation (AD_Process), compilation will be required. WAD needs to generate code.

Based on functional specifications described above, the following sections discuss technical details on each of them.

Implement all references

Currently, widgets are using the same parameter definition table and they are already implementing a good portion of existent references. Ideally, code for both artifacts (parameters in widgets and parameter windows) should be reused.

Display and read only logic

Note fields participating in these logics can be other parameters, which should be evaluated as they change, but they can also be session attributes as well as fields in window invoking the process. For this latter case, it must be decided whether in order to use a field in this logic, it is mandatory to set it as stored in session.

Validation rules

Currently validation rules restrict the selectable values in 2.50 style drop down lists (Table, TableDir and List references). With the following problems/limitations:

Knowing all this, should we still use validation rules? should we extend them? should we create something else?

Return complex actions

See 21689 21670.

No need of physical column

This would simplify development of new processes. Computed fields currently don't need physical column behind them, so this should be extended also to parameter windows.

Execute on more than one record

This is already implemented for manual UI process definition. It just requires to be extended to this functionality.

Callable from menu

Some Parameter Windows need to be invoked from menu.

Old 2.50 processes are opened in a popup which in most of the cases is modal. UI for this case must be decided: popup (modal/no modal), new tab...

Regarding implementation: P&E JavaScript class is served together with the window that includes it, this is done in this way in order not to request it when the button is clicked making the experience more fluid. In case of menu, code will be served on menu entry click, component serving P&E and parameter windows should be able to be rendered in both ways (together with a window and on demand).


Currently P&E processes are secured in the same fashion old processes are: by default, having access to a window, implicitly gives access to the process. It is through a preference that this behavior can be changed to force to have explicit access to the process.

In case of menu, explicit access is always required.

Additionally, process access must be checked in backend to ensure it is not executed by ungranted users. This should be implemented centrally.


A possible approach to implement reports:

Reports are processes that implement a known Handler, they must have a hidden parameter with the jrxml that prints the report. The handler receives this parameter as well as the rest of parameters, and generates the report.

UI Interfaces

The UI during process execution can vary depending on which interfaces implements the java processes. In this way it would be possible for example:

This interfaces, as well as UI implementation should be deployable by modules, so new modules could implement different visualizations for processes in execution.

To implement this feature it would be needed to have a pool of in execution processes, so it is possible to retrieve the instance of a known process to ask for its status.

From client side, this could be implemented doing pings for current processes each x time, or through webSockets or a similar technology.


If the pool defined above is current quartz scheduler, it might be relatively easy to make all Parameter Window processes schedulable. In fact, when calling from button, they would be scheduled tasks to be immediately executed.

This also would make visible all process executions from current Process Monitor window.

Implementing persisted parameters feature would make possible to schedule based on some parameters.

Persisted parameter values

Persisting parameter values, together with schedulable processes, allows to schedule the same process with different values.

Currently OBUIAPP_Parameter_Value table is used to store param values used for widget params. This is the table that should be used for this purpose.

Initially, it could appear as child of Process Request window to add all parameters for the scheduled process.

In a second phase parameters should be editable through a rich interface which would be displayed similarly to the parameter window.

Date Range reference

In case of parameter windows it makes sense to define a complex date reference that defines a range (from-to) in a similar way currently is implemented in grid filters.

Date range.png

User experience design

Notes to be considered when designing UI:


This project is divided in different phases.

Phase 1

Status: Implemented in 3.0MP20.

Implement all must have options:

Phase 2

Status: In progress, planned for 3.0MP25

Phase 3

Status: Not commited yet




Retrieved from ""

This page has been accessed 7,465 times. This page was last modified on 3 June 2013, at 09:02. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.