Basically I'm trying to see what is supported for filtering of screen data using pure JS rather than Query Designer and PreProcessQuery method. After stumbling in the dark through msls watching variables and banging head on
walls; either this is not supported or I just haven't found the right object to apply the filter.

Answers

Forcing a visual collection to have the results that you want is not supported.

The only way to do this is to back the visual collection with a query that returns the results that you want. Using optional query parameters, as has been suggested, is the best way to make a configurable query that returns different results based on the
dynamic filter that you want to apply.

In fact, this is how the
Filter Control sample works. It creates the filter expression, serializes it, passes to a query through a parameter, deserializes the expression in the PreprocessQuery method of the query, builds the expression, and applies it to the query object.

My suggestion is that you do something similar to what the Filter Control sample does.

All replies

Your code is close, especially in the second try. Both .load() and .filter() methods return a promise object that when fulfilled contain your data. The difference is that LightSwitch's API is programmed so that .load() will trigger the screen
Visual Collection to re-display but .filter() does not.

The results of the .filter() method will include an array results that has the filtered data.

screen.details.dataWorkspace.ApplicationData.Contacts.filter(filter)

.then(function(results) {

// do what you want with the results.results array containing your filtered query

});

The screen's Visual Collection is not affected by this query however. To do that, you're better off using LS' Query Designer unless there's some compelling reason not to. You stated, "Basically I'm trying to see what is supported for filtering
of screen data using pure JS rather than Query Designer and PreProcessQuery method." For what you are trying to do in this specific example, LS will take your Query Designer instructions and convert it to "pure JS" automatically, just look
at your data.js file to see what I mean. In this particular case, preProcessQuery does not need to be used.

Thanks Allen. I got so far as to see the results coming back from the .filter method, but I really want to know how to update the screens VC with a query. I hacked around with the loader objects to no avail.

The compelling reason: the query designer misses because you have to determine at design time the fields on which to allow filtering. I want to enable dynamic runtime filters on fields of the users' choosing. Same for dynamic
sorting.

I understand this can be done in a convoluted way using preprocess query (in which case you still must handle every field by name so the code is not reusable on another entity), but it seems there should be a way to load the VC from a query.

I'm in search of a way to do dynamic filtering and sorting without the need for a the linq dynamic query library, you might remember this post:

"the query designer misses because you have to determine at design time the fields on which to allow filtering.
I want to enable dynamic runtime filters on fields of the users' choosing."

I have some query screens that allow the user to filter from 6 different parameters in both the SL and HTML clients using the query designer. As long as the parameters are marked Optional in the query designer, the user decides what to filter with
and what to ignore.

Haven't seen Huy on here in quite a while. Perhaps he's moved on to another project.

ComponentOne's OLAP grid for LS (both SL and HTML) may have a functionality more to your specifications.

Thanks Allen I understand devs can use optional parameters to allow some choice for filtering. Not so for sorting. This still falls short in my view. LS uses oData filters in Uri to fetch data. All the filter string conversion is in the js client. So why
not allow us to query and refresh screens dynamically? Hopefully someone will present a way to override default loader query.

Forcing a visual collection to have the results that you want is not supported.

The only way to do this is to back the visual collection with a query that returns the results that you want. Using optional query parameters, as has been suggested, is the best way to make a configurable query that returns different results based on the
dynamic filter that you want to apply.

In fact, this is how the
Filter Control sample works. It creates the filter expression, serializes it, passes to a query through a parameter, deserializes the expression in the PreprocessQuery method of the query, builds the expression, and applies it to the query object.

My suggestion is that you do something similar to what the Filter Control sample does.

Thanks for your reply Justin. I was afraid of that. Field names cannot be passed into PreprocessQuery since OrderBy and Where require Lambda expressions. The bummer, IMHO, is that HTML Client has string based odata filters and we
still cannot manipulate the loader objects to enable dynamic filter sort at runtime.

What would be your opinion about adding the
Linq Dynamic Query Library to the middle tier so we don't have to serialize then deserialize then build lambda expressions?

This would open the door to a lot of dynamic runtime behaviors that are currently difficult to implement. Not to mention, prevent LS team from needing to include the same filter and sort extensions in all your samples (ie:
Customizing the Table Control Sortable by Column )