[Blama]

Hi Isomorphic,

thanks, that setting does indeed the necessary change. The FormItem then issues the fetchMissingValueReply-request.

1. I did see the small issue you described once in the last paragraph of #15, but I'm not sure how to reproduce. But it was with "Company 100", which is not in the 1st page of records, so this is in alignment with your text.
2. There is still the small validation error issue from the last video in #7.
3. Regarding the main problem in this thread: Wouldn't be a default of setUseLocalDisplayFieldValue(false) be useful in the testcase, perhaps set this when you call setForeignDisplayField() or always set this in ListGrid-editors (might be too aggressive)?

Anyway - thanks a lot, Depending on your position on 3. I'll now change this in my application and should be able to solve the issue here. I'll definitely have to change setDisplayField() to setForeignDisplayField() though the whole application, so I might change both (from this solved issue).

Best regards
Blama

[Isomorphic]

Hi Blama

On #3, we've been in discussion with the development team about potentially defaulting useLocalDisplayFieldValue to false for fields with a foreignDisplayField and this is not something we intend to change.

We would consider your use case a little unusual. In most cases the assumption is that a developer will want a consistent display value to be shown to a user for a field in a static ListGrid cell or in a live editor.

The common pattern is the one described in the Editing included fields section of the dataSourceField.includeFrom documentation.

To recap:

The foreignKey, displayField and includeFrom features provide a way to populate the display value on the record (without requiring the server to perform an additional fetch against the related dataSource). This value will be shown in both editors (formItems) and static ui (listGrid cells) for the record.

When in edit mode, the optionDataSource is used to show a list of possible options for the user to select from. If optionDataSource is not explicitly specified, the foreignKey declaration allows the framework to figure out the appropriate related dataSource and "valueField" for that dataSource. The displayField (within that related dataSource) can't be determined automatically (dataSourceField.includeFrom is a server-only feature and doesn't get passed down to the client), so foreignDisplayField is used to explicitly specify the field if it doesn't have the same name as the "local" display field.
The typical setup however is that this foreign displayField value will match up with the local displayField value.

In your usage of course it does not - you want a different field to be used as the optionDataSource display field in editors. This is fine - setting useLocalDisplayFieldValue to false explicitly on the editor configuration essentially "disconnects" the standard feature of picking up the display field from the local record within the edit-form. Instead it forces a fetch to occur against the optionDataSource. However the presence of a foreignDisplayField attribute isn't on its own an indicator that this is the developer's intention.

Incidentally, at this point the meaning of "display field" becomes unambiguous for the editors, so you could have "displayField" or "foreignDisplayField" set to "NAMETWICE" on the editor configuration - either would work. You could also omit that specification altogether and instead set the "titleField" on the company dataSource -- that will be used by default if no explicit display field is specified. We just mention this for completeness given that it sounds like adding "foreignDisplayField" specifications is a chunk of work for you. All this stuff is documented if you look at the docs for getForeignDisplayField() / getDisplayField() under FormItem.

Hopefully this clarifies things a bit. We'll respond to the other issues separately.

Regards
Isomorphic Software

[Isomorphic]

On this:

There is still the small validation error issue from the last video in #7.

We're not reproducing this with the latest version of the code, with useLocalDisplayFieldValue in place.
Can you verify that you are seeing it with the useLocalDisplayFieldValue setting. It may be worth re-sharing the EntryPoint code in case you have any local edits which may account for the difference.
Also, to re-state the steps:
1) You load the page
2) double click the cell to go into edit mode
3) show the drop down by clicking on the "down arrow" icon
4) click the icon again to hide the drop down
5) click outside
6) reload the page and go through steps 1-5 again, at which point you see the validation error

Is that accurate?

[Blama]

Hi Isomorphic,

thanks for the detailed explanation in #17. I don't have any problems with code changes as long as I know what to do. The use of foreignDisplayField is IMHO still needed for me, if fields have the same name in different DataSources, which is quite common for me (many DS with a "NAME" field). This was the (now solved) problem from this thread.

The issue / necessity for useLocalDisplayFieldValue(false) is as you write - show the value as it it will be displayed in the pickList once you open it. This setting will definitely not be needed always but it's good to understand how everything is connected here.



Re #18:
Your steps are correct, but it also happens the 1st time, so after 5) you see the validation error. If you want to see it again, you have to reload the sample, closing the window and clicking the "Recreate" button is not enough (this is from memory, as I'm at home now).
Important: The video is of course with the code of the video-post, so #7. No change and therefore no useLocalDisplayFieldValue setting, which was unknown to me as I wrote #7.
I did test this with Win10 / FF26 Legacy Dev Mode. If you can't reproduce, I can run tomorrow again with a) setUseLocalDisplayFieldValue(false) and b) SuperDevMode.


Best regards
Blama

[Isomorphic]

We did indeed try to reproduce, without luck. Please try with the latest code. SuperDev mode is unlikely to be a factor here honestly, but it's worth trying that as well just to be certain.

If it persists for you with the useLocalDisplayFieldValue in place, we'll take another look

Thanks

[Blama]

Hi Isomorphic,

but can you reproduce with the very same code, without setting useLocalDisplayFieldValue? This is how the video was made, and as I understood it, setting or not setting setUseLocalDisplayFieldValue(false) is more of a personal choice, how one wants the FormItem to look in ListGrid edit mode.

Best regards
Blama

[Blama]

Hi Isomorphic,

using v11.1p_2018-02-19 I can still reproduce, but only without setUseLocalDisplayFieldValue(false), this means with the exact code from #7, and only for ComboBoxItem, not for SelectItem and only for the top entry "Company 001", not for the others.

The steps are exactly as you describe.

It happens in FF26 Dev Mode and also in SuperDevMode.

Best regards
Blama

[Blama]

Hi Isomorphic,

although this is very minor for me now, there still seems to be some framework issue.

Best regards
Blama