client-side resultset filtered twice

[RickBollinger]

Before I go off in a screwball direction, I would like check if it is valid. My problem is that I am now using a clientOnlyDataSource to hold some issues (filtered on ProjectID) before I allocate them to topics in my now working three level listgrid. So far, so good.

But, I notice that they do not participate in updates to their original dataSource. What I need is a ResultSet, like in my other listgrids.

Is it as easy as just creating a named resultSet on an existing dataSource, give it my ProjectID criteria, and get my issue records to applyFilter again into my topics?

That would be really slick.

Rick

P.S. I am running SmartClient Version: v8.2p_2013-01-14/EVAL Development Only on Mozilla Firefox 12.0 with Firebug using Windows XP Pro 32 bit.

[Isomorphic]

Yes, you can simply create a ResultSet and assign a DataSource to it. Calling get(0) on it will trigger it to fetch from the DataSource (as will assigning it to a grid).

[RickBollinger]

Great! I wish I could create a resultSet with a global name, but I will have to stick in my Application variable.

I don't fully understand statements in the docs. I want to use "local" fetchMode, but I read that means

All records available from the DataSource are fetched. Filtering by search criteria and sorting are both performed on the client.

But, I want the criteria for the resultSet to be applied on the server so only issues for the current project are fetched client-side.

Then, I need to applyFilter later with criteria to allocate them to a number of listgrids. Client-side filtering is needed here.

I am probably reading too much into it. I will just proceed with my assumptions.

Rick

[Isomorphic]

The fetch modes behave as follows:

"local" - when you issue the first filter request, the client sends a request to the dataSource [typically this means "to the server", though for a clientOnly dataSource it's all handled on the client of course] with no criteria attached, so gets all available records transferred into a cache within the resultSet.
Once the data arrives, it is filtered on the client (and all subsequent criteria changes work with that same cached set of data, until you invalidate cache)

"paged" - when you ask for data, the resultSet sends a request to the dataSource with the specified criteria and a start/endRow, allowing the ResultSet to be a window into a huge data set without having to transfer all that data to the client at once.
Subsequent criteria changes will intelligently filter from the cached set of data if possible (criteria are more restrictive than what is currently cached, and the full set of data matching the criteria is present in the cache).

"basic" - similar to paged but without the startRow / endRow pages of data. The criteria will be passed to the dataSource when data is first requested, then when the criteria change, the resultSet data will apply a filter to the cached records if possible (IE - if the new criteria are more restrictive than the old).

Also note that you can explicitly seed the cache for the ResultSet using the "allRows" attribute, meaning that criteria will be applied to that cache of data directly with no need to directly issue fetch requests against the DS when the criteria change.

Let us know if this doesn't clear things up.

[RickBollinger]

Wow! That's a lot of reply.

My logs agree, unfortunately. All the issue records are retrieved and criteria are applied client-side. This works now, but does not scale.

I need server-side application of criteria so that only the issue records needed for a specific project are fetched. Otherwise, orders of magnitude of unneeded records are fetched and discarded. I am sure this would be noticed in application performance.

If I cannot apply criteria to a resultSet at creation time, I don't know what else to do besides doing my own fetch and figuring out how to get it into a resultSet so that it participates in updates on its dataSource.

Suggestions would be appreciated.

Thanks,

Rick

[Isomorphic]

You can create a ResultSet with a specific set of filtered data that you have already retrieved from the server by providing it as "allRows". You can also create a ResultSet that uses your clientOnly DataSource with already filtered data.

[RickBollinger]

I like all your suggestions. I looked at allRows. Unsaid is whether the resultSet is still linked to its dataSource and, more importantly, if its new rows would participate in updates to the common source.

Thanks,

Rick

PS: I am curious to know just when the criteria specified during creation of a resultSet are applied.