FilterBuilder

[pavel.tavoda@f4s.sk]

Hello,
for ListGridField you support filterEditorProperties and FilterBuilder is usually used with ListGrids.
Can't you instead of using editorProperties use filterEditorProperties for making fields for FilterBuilder?
Maybe best will be to use filterEditorProperties from field and only when it's not available use editorProperties. I'm speaking about code in FilterBuilder.js in lines 592-603 (Version v8.2p_2012-04-12).

plus small bug at line 594 'exitorType' -> 'editorType'

[Isomorphic]

Thanks for pointing out the typo, we'll fix that.

What did you have in mind here? Because the editors shown by the FilterBuilder actually change according to the operator, applying editorProperties is of limited use.

[paveltavoda]

You aren't setting/removing all important information in field. For example if you define startRow:true in field it's reused by FilterBuilder and field appear on new line (looks ugly). If you define canEdit:false field is read-only in FilterBuilder (unusable field). And many, many other fields which you have to control/reset to default for FilterBuilder.

For example for 'SelectItem' fields it's nice to define multiple:true in filterEditorProperties. In ListGrid in filter row than appear nice multiselect. It will be good to reuse this definitions for ListGrid also in FilterBuilder. In every case it's better to apply filterEditorProperties than editorProperties for filter fields.

[pavel.tavoda@f4s.sk]

Hello,
are you doing someting about this? Or is it just stupid request? Be honest I'm already big boy, I can live with it.

Thanks

Pavel

[Isomorphic]

We're confused as to what you're looking for here.

Again it seems that customizing the FilterBuilder editor at the *field* level doesn't make much sense, because the FilterBuilder shows a different editorType depending on the operator in use.

Are you saying that setting multiple:true just happens to work well for you because it only has an effect with the editorType happens to be a SelectItem?

[pavel.tavoda@f4s.sk]

Try following example:

isc.DataSource.create({
    ID: "countryDS",
    fields:[
        {name:"countryName", type: 'text', title:"Country", width:120, startRow: true},
        {name:"background", type: 'text', title:"Background", canEdit: false},
        {name:"countryCode", title:"Flag", align:"center", width:50, type:"image", imageSize:24, imageURLPrefix:"flags/24/", imageURLSuffix:".png"}
    ]
})

isc.FilterBuilder.create({
    ID:"advancedFilter",
    dataSource:"countryDS"
});

When you choose 'Contry' edit field apper on new line. When you choose 'Background' field for inserting value is dissabled (canEdit: false) and I can show other attributes which can damage FilterBuilder.
It will be useful to apply filterEditorProperties which can be embedded in field definition and doesn't apply for ListGrid or DynamicForm. We are reusing same DS definition for everything (ListGrids, DynamicForms, Views, Filters, ...), and we want have consisten behaviour between ListGrid filter and FilterBuilder as minimum requirement or at least what I expect as 'default' behavior.

[Isomorphic]

You shouldn't set startRow on a DataSourceField - it's not documented there and not allowed there, and FilterBuilder isn't the only component that would be damaged by setting it there.

If you have a field that is not editable but should allow filtering, set canEdit:false, canFilter:true.