great. good to know.
the javadoc could be improved here for these non-string cases (or multiple value string cases) , and perhaps made clearer with some examples. i would imagine the use of optionDataSource id->string is probably more common than an optionDataSource with just a string.
question: my workaround of doing the id->string and then string-id conversion on the server seems like it should not be necessary (i have not reverted my workaround since using filterdata instead of fetchdata) - i read you reply above as saying it was the correct way of doing this - this seems wrong to me; shouldn't the client code should handle id -> string mapping (and string -> id)
the javadoc could be improved here for these non-string cases (or multiple value string cases) , and perhaps made clearer with some examples. i would imagine the use of optionDataSource id->string is probably more common than an optionDataSource with just a string.
Description copied from interface: DataBoundComponent
Retrieves data that matches the provided criteria and displays the matching data in this component.
This method behaves exactly like fetchData() except that textMatchStyle is automatically set to "substring" so that String-valued fields are matched by case-insensitive substring comparison.
Retrieves data that matches the provided criteria and displays the matching data in this component.
This method behaves exactly like fetchData() except that textMatchStyle is automatically set to "substring" so that String-valued fields are matched by case-insensitive substring comparison.
question: my workaround of doing the id->string and then string-id conversion on the server seems like it should not be necessary (i have not reverted my workaround since using filterdata instead of fetchdata) - i read you reply above as saying it was the correct way of doing this - this seems wrong to me; shouldn't the client code should handle id -> string mapping (and string -> id)
Comment