OptionDataSource and Criteria

[fatzopilot]

When using the OptionDataSource "the entire set of records from the optionDataSource" is fetched "without paging" (java docs).
I wonder whether it is possible to pass criteria (e.g. indicating the calling datasource instance's primary key) to the corresponding fetch on the OptionDataSource as it does not seem to be done automatically. This would be a major improvement of the OptionDataSource feature imo.
What do you think?

[Isomorphic]

We think.. that's it's already there (optionFilterContext)

[fatzopilot]

Hm, I meant the Criteria should be added *dynamically* based on the calling datasource instance's primary key, so I wonder how a DSRequest which is required by setOptionFilterContext could be provided programmatically specifying this. Or did I mistake something? Here is the code:

ListGrid ds1Grid = new ListGrid();
		ds1Grid.setAutoFetchData(true);
		ds1Grid.setDataSource(ds1.getInstance());
		ds1Grid.setUseAllDataSourceFields(true);
		TreeGridField name = new TreeGridField("Name");
		TreeGridField lastIncidentID = new TreeGridField ("lastIncidentID");
		
		lastIncidentID.setAutoFetchDisplayMap(true);
		lastIncidentID.setValueField("id");
		lastIncidentID.setDisplayField("time");
		lastIncidentID.setOptionDataSource(ds2.getInstance());
		lastIncidentID.setOptionFilterContext(???);

[Isomorphic]

If what you're trying to achieve is something like databound dependent selects, just read the rest of the doc you were quoting before, and go on to look at the referenced sample.

If you want something else, try to be very, very specific about what you're trying to accomplish.

[fatzopilot]

OK, here we go:

There is a 1 on 1 relationship with the records in ds1 and ds2
I've overrriden the

protected void executeFetch(final String requestId, final DSRequest request, final DSResponse response) {

method of ds2 (used in setOptionDataSource() in the example).
It is called to obtain the missing field values for each record in ds1 from ds2. However, the request variable does not contain any criteria. It would be useful to have criteria corresponding to the records of ds1 for which the corresponding records should be fetched. That way, the result set could be limited to contain only the needed records from ds2 and not the entire set as described in the docs. For large datasets in ds2 this would imo be the better approach than the approach recommend in the docs (see com.smartgwt.client.widgets.grid.ListGridField.setOptionDataSource)

[Isomorphic]

Don't do that, follow the method indicated in the docs you were quoting before (deliver values from ds2 in the results for ds1, as the displayField).

[fatzopilot]

Well,

I just tried to use all the wonderful advanced settings that smartGWT provides and stumbled upon this inconvenience, thus the request for remedy.
But you are right, at least in my use case there should not be a problem with the approach described in the docs. Have to further figure that out though.

Thanks
fatzopilot

[Isomorphic]

?

The approach described in the docs is the right one. There is no more "convenient" way to provide this facility from the client-side (one fetch per record does not make sense).

[fatzopilot]

I do not know exactly how criteria could be composed but they may include a list of ids indicating which records should be contained in the result set.

[Isomorphic]

.. which would require two turnarounds for initial display, whereas the current method does it in one, and which would also require two turnarounds for each new set of records loaded, or any change that introduces a single new record or changes the field that has the optionDataSource.

Which is why that approach was discarded.

[fatzopilot]

OK,

I have not tested how the setOptionDataSource works exactly. Maybe it fetches the whole setOptionDataSource once, keeps it in memory, and reuses it to accomplish consecutive display updates if any.
Otherwise it requires at least two datasource queries for each display update as your described. So passing some additional criteria to the second query (to the OptionDataSource) would in this case provide the option to optimize the second query. Nothing more and nothing less.

[Isomorphic]

Yes, it fetches it once, keeps it in memory, and reuses it.

This is accomplished with one HTTP request containing two logical DSRequests (see RPCManager.startQueue() and the Transactions samples).

The two approaches in the docs - the approach above and the approach of returning display values in the original record - are the best approaches. Go over the series of requests required for your approach and compare it and you'll see why.

[fatzopilot]

Hm, I think I just trust your experience here... Thanks for the details and preventing me from bad practice ;)

[ectar]

When using the OptionDataSource "the entire set of records from the optionDataSource" is fetched "without paging" (java docs).
I' curious what JAVA

I'm curious what Java doc is quoted here
and how did you resolve this issue?
Because similar problem I'm trying to solve, - display list items based on another PK field value and have no clue how to do that.

[Isomorphic]

He quoted listGridField.optionDataSource. Read the rest of that doc (and the rest of the samples and doc references in this thread) for the right approach.