Problem with SelectItem.setOptionFilterContext

[Sytematic]

Hello,

Using (v8.2p_2012-07-30/PowerEdition Deployment 2012-07-30)


I have the following SelectItem:

SelectItem f = new SelectItem("participants_id","Examendeelname");
f.setOptionOperationId("myOperId");
DSRequest r = new DSRequest();
r.setOperationId("myOperId");
r.setDataSource("Exam_participants_Student");
f.setOptionFilterContext(r);

f.setPickListFields(
	new ListGridField("firstname", studentMessages.firstname()),
	new ListGridField("structureName", structureMessages.structureName())
);
ListGrid listGrid = new ListGrid();
listGrid.setShowFilterEditor(true);
listGrid.setFilterOnKeypress(true);
f.setPickListProperties(listGrid);

This is a selectitem with dropdown listgrid with filter editor above the header columns. If I type something in the filter field I get the following DSRequest being logged:

=== DEBUG RPCManager - Request #1 (DSRequest) payload: {
    criteria:{
        structureName:"fd"
    },
    operationConfig:{
        dataSource:"Exam_participants_Student",
        operationType:"fetch",
        textMatchStyle:"substring"
    },
    startRow:0,
    endRow:75,
    sortBy:[
        "surname"
    ],
    componentId:"isc_PickListMenu_7",
    appID:"builtinApplication",
    operation:"Exam_participants_Student_fetch",
    oldValues:{
        structureName:"fd"
    }
}

As you can see it is not using the supplied operationID 'myOperId'.

Am I misinterpreting this API ? I kind of want the filter be of the same operation Id as the one set by f.setOptionOperationId(). Is this a bug?

[Isomorphic]

setOptionOperationId() is the right way to provide the operationId.

We're not really sure what you have in mind about two different operationIds. What are the two types of requests that would have different operationIds?

[Sytematic]

I tried this setOptionFilterContext() method because earlier, when only using the setOptionOperationId() method, filtering didn't seem to use the specified operation Id.

So I was under the assumption that this was by design, and that setOptionFiltercontext was the way to specify an operationId for the filter.

So then it must mean it is a bug in that my nightly build ignores the operationId when using the filter inputs of the dropdown grid?

[Isomorphic]

If there is a such a bug, you'd be able to work around it by setting fetchOperationId on the pickListProperties - can you try that?

[Sytematic]

Yes that works! Thanks a lot, I can at least finish this functionality now. Have a good weekend.

[pghosh]

I am trying to set params using setOptionFilterContext for an optionDataSource

setOptionDataSource(dsAttrs);
setOptionFilterContext(new DSRequest(){{
  setParams(new HashMap<String, Object>(){{
    put("renderAs", "date");
  }});
}});

but I don't see them being passed to the server. Please verify.
Thanks.

SmartGwt v3.0p 07/31/2012 05:28

[Isomorphic]

We're not aware of an issue where setting params on the optionFilterContext would fail to pass these through to the server.

Could you show us a simple, runnable test case (entry point class) that defines and renders a select a SelectItem and exhibits this problem.
Also please be sure to indicate exactly how you're determining that the parameters are not present. A simple check is to look at the RPC tab in the developer console. You should see the params on the "RPCRequest" tab in the request details section.
You can also look at the transaction (using in-browser developer tools or something like firebug or fiddler), and of course look at the transaction as it arrives at the server.

Regards
Isomorphic Software

PS: It may also be worth trying the 3.1d branch, if upgrading to 3.1 is an option for you. This may be something that has already been resolved since 3.0.