Toolbox

There is a requirement to also visualize indirectly linked information. For example when in the sales order window it should be possible to display and filter:

on the name of the bank of the bank account of the business partner of the order.

This is supported in the selector definition but not in ad_field. The proposal is to make it possible in ad_field to define a property path to include indirectly linked information in a grid and form. For the example this would be: businessPartner.bankAccount.bank.name

Both filtering and sorting should be supported.

These type of fields are non-editable.

Feature overview

allow property path definitions in ad_field
use the property path instead of ad_column when generating the field definition for a form and grid
support grid visualization for these fields
support filtering and sorting on these fields
also handle these fields correctly when inserting new records, at insert the system should return the indirect properties also
the new field will be display only, the display will be updated when a record gets saved (not when other fields get updated).

Users & use cases

For the user the new field will be the same as a current display field.

Design

Functional specification

Technical specification

Model Changes

add a new field to ad_field: property, it should be the same as the property field in obuisel_selector_field.property. Preferably the same reference can be used. One thing which needs to be checked is if the table of the parent (ad_tab) is correctly passed in/used to filter possible model properties. It is a non-mandatory property.
ad_column_id and this new field are mutually exclusive, when one is set the other should be hidden and vice versa.

Server Side Changes

The functionality is similar to what is supported for selector fields. The datasource has the concept of extra properties which are returned next to the properties of the entity itself. To get an overview of existing implementation, search in the java code for the occurence of the constant:

JsonConstants.ADDITIONAL_PROPERTIES_PARAMETER

When generating the datasource for a tab (see the OBViewTab class and the getDataSourceJavaScript method) the properties which are not part of the table should be passed in as extra properties. All ad_fields which have a property (instead of a column) should be collected, the properties should be appended to one string, comma-delimited and passed to the datasource creation as a parameter in the hashmap:

public String getDataSourceJavaScript() {
    final String dsId = getDataSourceId();
    final Map<String, Object> dsParameters = new HashMap<String, Object>(getParameters());
    dsParameters.put(DataSourceConstants.DS_ONLY_GENERATE_CREATESTATEMENT, true);
 
    // NEW LINE----->
    dsParameters.put(DataSourceConstants.ADDITIONAL_PROPERTIES_PARAMETER, concatenatedCommanDelimitedProperties);
    // <---- NEW LINE
 
    dsParameters.put(DataSourceConstants.DS_CLASS_NAME, "OBViewDataSource");
    final Component component = componentProvider.getComponent(dsId, dsParameters);
    return component.generate();
  }

The new types of ad_field should be outputted in the same way as the other fields. The new field should use the OBStaticTextItem as the field type, they should always be read-only.

The code in the org.openbravo.client.application.window which generates the fields (for tab/grid/form) should be checked for when it uses ad_column. This code should be changed to handle a property definition (to retrieve the property and element).

The template file ob-view-tab.js.ftl also generates a javascript array of property to column mapping (propertyToColumns). The code should be adapted so that the fields without column are not made part of this array.

WAD: the WAD generation should ignore any ad_field without an ad_column set. This development is also part of this proposal.

Client Side Changes

The new fields should be shown as read-only in the form.

It should be checked that when inserting a new record or changing a record/form that the new field is recomputed when saving the record. There can be some complexities there, as the extra properties are computed on the server. So when saving, the extra properties get returned from the server and need to be re-displayed on the client. This should normally work fine:

The json data source should return the inserted/updated record with the additional properties back to the client.
Smartclient should automatically integrate the returned information from the server into the existing record on the client.

Relation to other development work

This proposal is related to the CanvasField proposal. In that proposal a flexible javascript field is proposed. To align these development with this one:

if a field is a javascript field the new property field should be hidden in the ad_field tab (in the window/tabs window).

User experience design

Planning

The proposal is to deliver this solution for MP4 together with a howto with some examples.

The development effort:

Model and window/tab/field side changes: 4 hours
Server side changes: generating different field, adding properties to the datasource, WAD: 12 hours
Client side changes: checking behavior when creating new records and updating, 4 hours
Documentation: 4 hours
Testing: 4 hours

Development

Tracking

This feature development is tracked using the following issue(s): to-be-added

Implementation

Documentation

The new development should be explained in a HowTo with a small example.

Resources

Retrieved from "http://wiki.openbravo.com/wiki/Projects:PropertyField"

This page has been accessed 2,409 times. This page was last modified on 8 June 2012, at 05:30. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.