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

Projects:PropertyField

Contents

Status

Team

Definition

Currently an ad_field has a direct reference to ad_column, and the ad_column must be a column of the table defined in the tab.

This means that only information of the table itself can be visualized in the grid/form, but no indirectly referenced information.

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

Users & use cases

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

Design

Functional specification

NA

Technical specification

Model Changes

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:

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:

User experience design

NA

Planning

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

The development effort:

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.