Can filter builder option values be set from database table

[wwarriner]

SmartClient version v10.1p_2016-11-11/PowerEdition deployment ( built 2016-11-11)

Is it possible to set the option values ( value I want to filter on) for a given field in a filter builder from a database table. That is set the various fields options values from various datasources ?

Thanks

[Isomorphic]

It’s not quite clear what you mean.

You can set fieldDataSource if fields are a dynamic set to be fetched from a DataSource.

You can have custom valueField properties if you want to use, for instance, a SelectItem with an optionDataSource for a dynamic criterion.value.

[wwarriner]

Sorry for the confusion.

Let me try again:

the selectItem has a method setOptionDataSource that: "If set, this FormItem will derive data to show in the PickList by fetching records from the specified optionDataSource"

Id like to configure field selectItems in a FilterBuilder to do exactly that, but its not clear to me how to do this. Since the filter builder is driven by a XML datasource definition I'm guessing it could be part of the datasource XML field definition ( field properties); similar to a valueMap element that can be used to define a static pick list. If that's the case its not clear to me how to do this in datasource XML. If not Id appreciate you pointing me in the right direction.


Hope this clarifies and thanks

[wwarriner]

So I created a datasource for the table field I wanted to populate the option list from and added a optionDataSource="myOptionDs" to the XML for a given field and that seems to work.
Is this the best/recommend approach ?

If so a couple of additional questions
1. Is there a way to force this to be cached - ?
2. Is there a way to configure the option list to allow users to type values into in order to support searches ( queries) such as starts with, ends with, contains, etc

Thanks

[wwarriner]

To be clear in my last post:
we have distinct values which employ a common prexfixes/suffixes. Users often want to see a all data with a give prefix or suffix. Id like to be able to support users entering the pre/suffix independently of whats displayed in the option list.

Thanks

[Isomorphic]

As we said before:

You can have custom valueField properties if you want to use, for instance, a SelectItem with an optionDataSource for a dynamic criterion.value.

FilterBuilder has an API getValueFieldProperties() which is an override point so you can set properties on the valueField, such as optionDataSource, and optionOperationId which will allow you to have a special fetch operation with the behaviors you want.

Note also it is not correct to set optionDataSource in .ds.xml - note it's not documented there. You can set the foreignKey attribute and that has a similar effect in the specific case of a SelectItem ending up bound to the field.

[wwarriner]

Thanks Ill check that out.

BTW where is what's allowable and not in the ds.xml defined. Is there a schema or documentation ?

[Isomorphic]

Yes, you’ve already been using it: the entire docs.serverds Javadoc package.

[wwarriner]

k thx

[wwarriner]

Thanks for pointing me to the getValueFieldProperties, worked great.

I'm wanting one more customization of the filter builder, I would like for some fields ( Field as in ds xml field) to be conditionally included/visible/enabled/non-functional. Is there a way to customize the FilterBuilder to achieve this ?

Thanks

[Isomorphic]

You can pass a DataSource with limited fields. To avoid duplication, use DataSource.inheritsFrom to inherit from the original DataSource.

[wwarriner]

I know about that but was hoping to handle it in the FilterBuilder. I can disable the Filter Builder value list, If I could disable the associated operator Form Item that would be acceptable. Any way to do that
thx

[Isomorphic]

Please look at DataSource.inheritsFrom - this is going to take just a handful of lines of code, inline, right in your FilterBuilder definition.

Your proposed approach is more complicated and far worse UE.

[wwarriner]

So thanks for your help its really appreciated, but I have to disagree with your assumption. I can think of and have couple of use cases where a filter value may: be displayed but optionally read only , modified by some global value( like date ), and persisted. Requiring 2 different data sources requires additional code to make this seamless ( Since a builder doesn't handle fields not declared in its datasource xml ( I tried it))- essentially I have to manipulate the delta between the 2 data sources. And BTW I've used datasource inherits extensively and its great - wish it supported operation bindings inheritance though.

I think it would be an acceptable option ( like 1 line to disable the operator form Item ( you can disable the option list now), and easier than adding a new data source.
Anyway not trying to be argumentative - The filter builder is a very nice tool and pretty flexible, still I think this would be a usefull addition.

So for now its DataSource.inherits ;-)

Thanks again

[Isomorphic]

So again, you just use this DataSource to configure the FilterBuilder. You don't use it to perform any operations. So there is no need for anything to be inherited except fields. There is no need to bounce between two DataSource definitions because the inheriting DataSource is only client-side code and only consists of a list of fields.

If you have use cases such as read-only fields, those would be configured via valueFieldProperties, and that works exactly the same regardless of what approach is taken to limit fields.