Data binding not supported for sap.ui.model.Filter value1/value2 properties

UI5 Version 1.22.3 (built at , last change) User Agent Chrome/36.0.1985.143

Reproducable example: http://jsbin.com/nehato/2/edit?js,output

See also: http://stackoverflow.com/questions/25387580/not-possible-to-set-filter-value-using-data-binding

Steps to reproduce:

If I use a filter where the filter value value1 is specified by data binding:

new sap.ui.model.Filter({
    path     : "division", 
    operator : sap.ui.model.FilterOperator.EQ, 
    value1   : "{/someProperty}"
})

then the dropdown does not render any items

However, if I hardcode a value at property value1:

new sap.ui.model.Filter({
    path     : "division", 
    operator : sap.ui.model.FilterOperator.EQ, 
    value1   : "Test"
})

then the filter works as expected.

Possible root-cause:

As Allen Zhang discovered in the aforementioned Stackoverflow topic, the Filter’s properties oValue1 and oValue2 do not parse any data binding path:

/**
 * Provides a JS filter function for the given filter
 * @name sap.ui.model.ClientListBinding#getFilterFunction
 * @function
 */
ClientListBinding.prototype.getFilterFunction = function(oFilter){
    if (oFilter.fnTest) {
        return oFilter.fnTest;
    }
    var oValue1 = this.normalizeFilterValue(oFilter.oValue1),
        oValue2 = this.normalizeFilterValue(oFilter.oValue2);
    //etc...

(Source code here: https://openui5.hana.ondemand.com/resources/sap/ui/model/ClientListBinding-dbg.js)

Reasoning why it should work with databinding

Imagine you have a table, and one of the columns shows a dropdown box for each entry in the table. The entries in the dropdown box have to be filtered based on a value in the current table row (for instance, each row in the table has a client field, and the dropdown should only list the projects for that corresponding client:

In code:

oTable.addColumn(new sap.ui.table.Column({
    label: new sap.ui.commons.Label({
        text: "Projects"
    }),
    template: new sap.ui.commons.DropdownBox({
        selectedKey: "{tablemodel>project}",
        items: {
            path: "metadatamodel>/allprojects",
            template: new sap.ui.core.ListItem({
                text: "{metadatamodel>projectDescription}",
                key: "{metadatamodel>projectKey}"
            }),
            filters: [new sap.ui.model.Filter("projectClient", sap.ui.model.FilterOperator.EQ, "{tablemodel>client}")]
        }
    })
}))

Explanation

1. The table records contain, among others, a field client and project
2. The dropdown template control in the table column is bound to a property allprojects which contains an array of objects {projectKey : "zzz", projectDescription : "zzz", projectClient : "someClient"}
3. The dropdown template has a filter, which filters the dropdown’s model property projectClient based on the corresponding table model array item’s property client

[ecker]

@rikusv @qualiture It’s been quite a while that this feature request had been brought up. Thanks for all your input and we apologize for the delays. Now we started to review the topic with our binding experts, again. Unfortunately, we don’t see to address it properly and suggest to keep using more explicit coding, typically in the controller.

Some reasons why we no longer consider an implementation (even that we had plans to do so back then): In order to benefit from the existing data binding capabilities one would turn the rather simple Filter objects into ManagedObjects (instead of reimplementing relevant parts in a redundant way). Only the comprehensive feature set of ManagedObject would allow to address reasonably powerful binding expressions in a dynamic filter. Just to use limited binding features wouldn’t cover some expected, real-life scenarios, e.g. referring to another model within the binding expression. Thus, one would need to have full lifecycle support for model creation, binding updates, etc. How and when to process different binding updates isn’t straightforward. Such implicit behavior could trigger some awkward update effects in (non-trivial) apps.

Therefore, in many real app scenarios we still advise to keep having more control about (re-)applying an updated filter or a set of filters, respectively. We suggest to go for the typical coding, albeit less elegant than the proposed dynamic filter declaration. As an example along those lines:

• if model isn’t available yet, attach to modelContextChange event in control
• use bindProperty() to create bindings for the filter values
• attach to change event of those bindings
• in handler (re-)create filter objects with those values
• (re-)apply those filter objects on the binding to be filtered

Hope that helps, and the more explicit coding also comes with some benefits (such as more control and less implicit update flows).

[matzeeable]

Is there any feature update yet? Or a “workaround” for this?