12.0p ComboBoxItem pickListProperties fetchOperation not valued

[Blama]

Hi Isomorphic,

I try to set up different requests (same DataSource, different operationID because of what happens on the serverside) (like in this post) for ComboBoxItem's (applies most likely to SelectItem as well) fetchRemoteDataReply and pickList data fetch. This here is not working even though I think it should.
Both fetches are using operationId "myMissingValueFetch", while I'd expect the pickList fetch to use "myDataFetch".

Please see the modified sample below (v12.0p_2020-05-14).
I'll try with optionFilterContext next.

Best regards
Blama

isc.DynamicForm.create({
    ID: "testForm",
    width: 500,
    items: [{
        name: "itemName", title: "Item Name", editorType: "ComboBoxItem", valueField: "itemID",
        addUnknownValues: false,
        defaultValue: 1000,
        optionDataSource: "supplyItem",
        optionOperationId: "myMissingValueFetch", [B]// Added[/B]
        width: 250,
        pickListCellHeight: 50,
        pickListProperties: {
            fetchOperation: "myDataFetch", [B]// Added[/B]
            canHover: true,
            showHover: true,
            cellHoverHTML : function (record) {
                return record.description ? record.description : "[no description]";
            },
            formatCellValue : function (value, record, field, viewer) {
               var descStr = record.description ? record.description : "[no descripton]";
               var styleStr = "font-family:arial;font-size:11px;white-space:nowrap;overflow:hidden;";                                  
               var retStr = "<table>" +
               "<tr><td ><span style='" + styleStr + "width:170px;float:left'>" + record.itemName + "<span></td>" +
               "<td align='right'><span style='" + styleStr + "width:50px;float:right;font-weight:bold'>" + record.unitCost + "<span></td></tr>" +
               "<tr><td colSpan=2><span style='" + styleStr + "width:220px;float:left'>" + descStr + "</span></td></tr></table>";
               return retStr;
            }
        }
    }]
});

[Blama]

Hi Isomorphic,

this is not working either, unfortunately:

isc.DynamicForm.create({
    ID: "testForm",
    width: 500,
    items: [{
        name: "itemName", title: "Item Name", editorType: "ComboBoxItem", valueField: "itemID",
        addUnknownValues: false,
        defaultValue: 1000,
        optionDataSource: "supplyItem",
        optionOperationId: "myMissingValueFetch",[B] // Added, working[/B]
        width: 250,
        optionFilterContext: {
            operationType: "fetch",
            operationId: "myDataFetch", [B]// Not working, but valid property[/B]
            sortBy: "units" [B]// Added, working[/B]
        }
    }]
});

Best regards
Blama

[Blama]

Hi Isomorphic,

turns out the way from #1 is working (=different operationId for fetchRemoteDataReply and pickList-fetch) if I leave away optionOperationId: "myMissingValueFetch" (but this is still a bug IMHO because it should also work with a different fetch than the normal fetch with no operationId).

In #2 this is not working if I do the same (operationId "myDataFetch" then in for both fetches).

Best regards
Blama

[Isomorphic]

This doesn't make sense. If the missing values doesn't return values for everything in the pickList, that would be broken; if it can return *more* than the pickList, that's useless. So why would you want a different operationId here?

If it has to do with some kind of optimization for single records, you can use just one server codepath, but turn on the optimization when the PK is provided, and then that would work for this case and others.

[Blama]

Hi Isomorphic,

the problem/usecase here is your 2nd point: "If it can return *more* than the pickList, that's useless". This is not true IMHO.

This is the situation:

• There is an entry (our main entity is lead) that links to a campaign via lead.campaign_id -> campaign.id.
• If you edit the lead, you can select from a list of campaigns, which have runtimes and grants. (It does not make sense to add new leads to an old campaign and not everyone can add leads from every campaign)
• These criteria that filter out unwanted entries are in a the serverMethod for the pickList (and currently also remoteDataReply fetch)
• This leads to the fact that persons, who can edit the entry see a picklist with an (currently selected) id and on open of the pickList they see their entries.
• It should be the way, that they see the currently selected name (not id) - pickList stays as it is.
• Therefore the fetch for pickList and remoteDataReply must be different

As written in #3 this is already working in one case, but this is not very effective, as you then are forced to use the default fetch for the remoteDataReply and can't use e.g. an operationId="fetchRemoteDataReply", as this breaks once you set optionOperationId.

Best regards
Blama

[Isomorphic]

In a nutshell, are you saying, the current value of the field may be something that they are not allowed to pick - they need to change it to something else?

[Blama]

Yes, that is the very short version :)
Even if they don't change it, it should of course display the text of the current selection, not the ID (e.g. in a disabled form).

[Isomorphic]

OK, this is already straightforward to achieve via different criteria in each circumstance, without a need for the operationId to be different.

We don't want to provide an official way to declare different operationIds, since the behavior of the two operations actually can't differ in any way except criteria anyway.

So if we had two separate operationId settings, we would be in the silly circumstance of having the documentation have big bold warningstelling people that even though these settings for different operationIds exist, the operationIds absolutely must not differ in any way except having different default criteria... which is already well handled by other approaches... so this is redundant and ripe for confusion.

[Blama]

Hi Isomorphic,

that is true and I assumed such an answer and thought it might be a source of errors. What about cases where the pickList criteria are complicated and computed in a DMI, like here?
You can't move every criteria clientside. So IMHO it must be possible to have serverside added pickList criteria while still having an easy way to do a dumb "criteria-free" fetchRemoteDataReply.

One other way (besides different operationIds) I could imagine to do this is to look for "fetchRemoteDataReply" in the DSRequest in the DMI on the serverside. I assume it would be possible to get this data there already now(?), but of course a getter boolean DSRequest.isFetchRemoteDataReply() would be preferred, also because the string "fetchRemoteDataReply" is not documented anywhere.

Best regards
Blama

[Isomorphic]

The client-side does need to be aware of the extra criteria applied to the pickList if you expect client-side filtering to work (which is important for performance). There is no other way that could work... we need the criteria in the browser if filtering is to be performed in the browser...

Outside of that concern, there is no restriction in the API that criteria must be applied at the client side in the comboBox - you could apply them any way you like, at multiple client-side and server-side layers.

We have already suggested (#4 above), in the context of optimization, that you could have your server-side code return any record so long as the PK was provided, which solves this use case as well.

[Blama]

Hi Isomorphic,

performance is not an issue here. It does not matter where the criteria are applied, as paged 0-75 load and additional criteria from the text entry still work.

You are right, your suggestion from #4 is the same if(pkCriteriaPresent) that I'd use with the suggested isFetchRemoteDataReply().
So I can solve my case even today, which is great, thanks.

isFetchRemoteDataReply() is then just a wishlist entry, as this makes the use case more declarative and easy to understand.

Then the issue at hand here is perhaps, that in some cases (see #3) the operationIds can indeed be different.

Best regards
Blama

[Isomorphic]

About #2/#3, if you're saying that you managed to force the operationIds to be different via pickListProperties, that's not something we're going to try to catch - it's kind of like using the AutoChild system to do something the docs definitely say is a bad idea: we can't catch all such cases, so we just assume you will follow the docs and not do evil stuff :) Plus, it's not even definitely something that would break behavior, as we've covered (it's find if the fetchMissingValues operation offers access to a superset of the records shown in the pickList).

If there's somewhere where you'd suggest a doc enhancement - perhaps somewhere we need to make a more explicit statement that the operation used for fetchMissingValues vs the pickList *must match*, let us know.

You had another thread where you suggested some interlinking between relevant properties, and we do already plan to do that, thanks.

[Blama]

Hi Isomorphic,

yes, that's what I meant about #2/#3. Fine for me, then.

W.r.t. to the docs:
The stuff with the operationId should be clear as everyone trying this will come across setOptionCriteria() which then suggests how to solve this case if it needs to be done serverside.
"Note that if you want to ... this request can be recognized serverside via request.getCriteriaValue()."

Therefore it's IMHO the mentioned interlinking + "what is fallback for what mentioning" between setPickListCriteria() and setOptionCriteria() as well as perhaps mentioning the word "fetchRemoteDataReply" in the latter, so that it can be found in the docs. Additionally perhaps the suggestion with if(pkCriteriaPresent) as way to recognize a fetchRemoteDataReply in the latter.

Best regards
Blama