Projects:NewCallout

Contents 1 Status 2 Team 3 Definition 3.1 Feature overview 3.2 Users & use cases 4 Design 4.1 Functional specification 4.2 Technical specification 4.2.1 AD_Field Changes 4.2.2 Server Side Changes 4.2.3 Client side changes 4.3 User experience design 5 Planning and Development Effort 6 Development 7 Tracking 7.1 Implementation 7.2 Documentation 8 Resources

Status

• Stage: Definition
• Planned Release: MP4
• Status Notes: Proposal

Team

• Contact: Martin Taal (martin.taal@openbravo.com)

Definition

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:

• the definition and implementation is complex as you need to code in java and generate javascript on the server.
• 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.

Feature overview

• 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:
  • logic can be completely implemented in javascript
  • 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

Design

Functional specification

NA

Technical specification

The proposal is to make it possible to define a javascript function which is called when the value of a field changes in the UI. The javascript function can then perform specific actions (set the value of other fields, call the server, etc.).

AD_Field Changes

• add a new column to AD_Field: onChangedAction: varchar, 200 (or more length), non-mandatory
• the new column will hold a string denoting a global javascript function to be called

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:
  • item
  • newValue

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

NA

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:

• base development (change to ad_field, initial client side javascript): 6 hours
• 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.

Development

Tracking

This feature development is tracked using the following issue(s):

• https://issues.openbravo.com/view.php?id=18588

Implementation

TBD

Documentation

• How_to_create_client_side_callout_onchange_function

Resources

• How_to_add_a_button_to_the_toolbar#Adding_server_side_logic_-_Implementation_steps
• Client_Side_Development_and_API
• Openbravo_3_Architecture#Implementing_Server_Side_Actions_callable_from_the_client