- Stage: Definition
- Planned Release: MP4
- Status Notes: Proposal
- Contact: Martin Taal (firstname.lastname@example.org)
Current callouts are defined in the application dictionary and always require a server side implementation and a call from the client to the server. This has the following drawbacks:
- has severe performance drawbacks as user edit actions in a field require a call to the server. The user interface is blocked during this call.
The idea is to make it possible to define a client side callout mechanism. Which does not force the developer to implement logic in the server side. The client side callout will have access to the client side environment (form, grid, current record etc.). If needed the client side implementation should have the possibility to do a server side call.
- Make it possible to define a client side 'callout' mechanism which can be implemented completely on the client
- The new logic should operate next to the current callouts, so it should not limit or break existing technology
- The new logic should still allow server side calls. Server side calls are asynchronous, the user should not be able to make changes while the server side call is ongoing. This means that the user interface should be disabled explicitly also in case of the new logic (only if it does a server side call!). The same mechanism as now can be used.
- The new logic should be extendable so that modules can add call out functions to a field with the option to overwrite the core callout. This can be achieved by adding a callout registry which allows modules to add callout functions which are called when a field/form/item changes.
- It should be possible to define a call order if there are multiple callout/onchange functions for a field
- It should be possible to override/replace a callout/function
- If a new callout/onchange is defined for a field then the classic callout mechanism is disabled.
Users & use cases
There are 2 types of users:
- Developer: the developer implementing the new client-side callout. For the developer the idea is to make it much simpler to implement new callouts, specifically:
- no rebuild is necessary when adding new logic
- End User: the end user will not see the implementation details but should notice a more responsive user interface
- add a new column to AD_Field: onChangedAction: varchar, 200 (or more length), non-mandatory
Server Side Changes
- the freemarker templates (in org.openbravo.client.application.templates) which generate the field definitions should include the onChangedAction value.
Client side changes
- capture the changed event on a field and call the onChangedAction if it is defined
- the onChangedAction should be a function, three parameters will be passed:
From this information the rest of the system can be reached (item.form, item.form.view, etc.).
- provide an easy integration with the FIC call infrastructure which disables input in the form. the purpose is to make it easy to disable the ui if a server side call is needed.
For server side calls the new callouts can make use of the ActionHandler concept. See this
User experience design
Planning and Development Effort
The feature seems light weight to implement and can give a lot of benefits for performance. It can make sense to implement the feature as quickly as possible. The proposed planning:
- deliver the following in MP4:
- the feature itself
- a howto (documentation)
- adapt a selected set of callouts in the system, the ones which give the most performance benefits
- In later MP's convert more current server side callouts to a completely client one of the current callouts in the system
The development effort:
- make it possible to easily disable the form when doing server side calls: 4 hours
- documentation: 2 hours
Re-implementing current callouts can not be estimated, it depends on the logic in each callout.
This feature development is tracked using the following issue(s):