The Filter service parameter

Hello Valeriy,

The filter parameter is a free form string.

In a Business Entity class, the filter parameter is generally assigned to the FILL-WHERE-STRING of the data source.

This means that you could pass a WHERE clause with multiple parameters.

However, I would prefer to pass the parameters in the string using different approach. Since just assigning the string would allow the client to pass parameters that you do not expect.

You could pass the parameters in string separated by commas or even use JSON.stringify() on the JavaScript side and pass an object with the parameters as properties to the backend.

Then in the backend, you would process the filter string and construct the FILL-WHERE-STRING.

This would prevent someone from constructing a WHERE clause that you are not expecting.

I hope this helps.

To follow up Edsel's answer, the AutoEdge Mobile sample that is available in the PDSOE Samples page passes JSON in the filter parameter, in case you want an example of this.

-- peter

Thank you. With AutoEdge I'll try to understand...

Another question, about it is written somewhere in the documentation for the OpenEdge? I have not found.

The point about the 'filter' parameter to a ReST interface, is that it is a free-form string, so that it can be interpreted any way you want (in your application).    You could use it as a WHERE clause for a dynamic query.  You could use it for text searches (i.e. CONTAINS), or as a single primary index value/filter.

Really it a s pattern, not a defined API, and as such I am not sure where it should show up in documentation.   The AutoEdge Mobile sample is a good place to show an 'example pattern'.

At some level, there is nothing that even requires that the OE Mobile front-end use the queryString/parameter with a name of 'filter'.   It could be almost anything.

Thank you all! I understood.

To send multiple values ​​in the Filter parameter, you can use JavaScript, for example:

return '{"searchString":"' + value + '", "TitleText":"' + $('input[name=TitleTextRadioGroup]:checked').val() + '", "WordsPhrase":"' + $('input[name=WordsPhraseRadioGroup]:checked').val() + '", "ProdGroup":"' + Appery('ProdGrpSelectMenu').val() + '"}';

My view is that the filter should NOT be used to pass a WHERE clause to the BE. This would require the UI to have detailed knowledge of the database at the back end. The whole point of this architecture is to separate business logic from UI. So the filter should be used to pass a message in UI terms of what it requires to be delivered and it is the responsibility of the back end logic to translate this into queries specific to the database used. This means that the same UI can be used with different back ends. Of course, this means you have to define a protocol that is used by the UI to specify its requirements that is interpreted by the back end but that would be necessary anyway. For example, in a product search, "E:999999999999" might mean "find product with EAN code 9999999999", whereas "D:xxxxxxx" might mean "return all products with xxxxxxx in the description". It is then up to the BE to create appropriate queries and to reject filters that don't conform to the published protocol.