Bug / Enhancement / General question: FK-lookup in DynamicForm SelectItem

[Blama]

Hello Isomorphic,

I'm using SmartGWT 4.1p (v9.1p_2014-12-06) and have a question regarding the short-time display of key-values in a DynamicForm:
I have a DS with the following field:

<field foreignKey="T_LEADTEMPERATURE.ID" name="LEADTEMPERATURE_ID" displayField="LEADTEMPERATURE_NAME" title="Leadtemperature" type="integer"
		required="true" />
<field includeFrom="T_LEADTEMPERATURE.NAME" name="LEADTEMPERATURE_NAME" hidden="true" />

In my DynamicForm I do display this field with

final SelectItemLeadtemperature leadtemperatureSI = new SelectItemLeadtemperature("LEADTEMPERATURE_ID");
setFields(...)
fetchData(...)

(actually it are some text fields and 3 FK fields, thereof 2 with SelectItem and 1 with ComboBoxItem)

The class definition is:

public class SelectItemLeadtemperature extends SelectItem {
	final private DataSource leadtemperatureDS = DataSource.get(DatasourceEnum.T_LEADTEMPERATURE.getValue());

	public SelectItemLeadtemperature(String name) {
		super(name);
		setOptionDataSource(leadtemperatureDS);
		setValueField(leadtemperatureDS.getPrimaryKeyFieldName());

		setDisplayField("NAME");
		setSortField("POSITION");

		setOptionCriteria(new AdvancedCriteria("AVAILABLE", OperatorId.EQUALS, true));

		setBrowserSpellCheck(false);
	}
}

This setup should be very common in every(?) application using Foreign Keys.

Now, upon load of the DynamicForm I can see the Leadtemperature-ID for a short time before the displayField from the databound SelectItem is displayed. Obviously this effect/timespan is larger in DevMode, but nevertheless still visible in Compiled mode. As requests to the main DS and the FormItems are not queued, depending on network quality, the effect can even be visible for the non-developer-eye.
For ComboBoxItems, the string "Loading" is displayed, instead.

As I really don't like showing the IDs to the end user, my question is if you think this is a bug and can show the "Loading"-string message for SelectItems as well.

Besides, my enhancement suggestion is the following: If the field in the main DS has a displayField, show the main-DS's displayField instead of the main-DS's field (the ID value) while the FormItem is loading its data.

Best regards,
Blama

[Blama]

testcase added

Hello Isomorphic,

please see the SelectItem in the sample in this thread.

Best regards,
Blama

[Blama]

Hi Isomorphic,

do you see the issue as well?

Best regards,
Blama

[Isomorphic]

Yes, we do see some inappropriate behavior - we're taking a look

[Blama]

Hi Isomorphic,

just to let you know - for me this is still happening in 4.1p (v9.1p_2015-02-17).

Best regards,
Blama

[Blama]

Hi Isomorphic,

just to let you know - this is still happening for me in 5.1d (SNAPSHOT_v10.1d_2015-03-25) and 5.0p (same date).

Best regards,
Blama

[Isomorphic]

This has sat for a while without a response - sorry for the silence.
We were reproducing some odd behaviors in this area but this appears to have been a result of how we were testing rather than anything else.

More to the point we're not actually reproducing a problem like the one you describe with the sample in the first post here.

Let's stick with the 5.1d branch (as the active development branch), and go back to basics.
Can you show us the full test case code we need to reproduce the behavior you're describing (running against this branch), and please be sure to describe the exact steps you're taking when you've loaded the test case, and which particular SelectItem is misbehaving in the resultant UI.

Once we are definitely seeing exactly what you're describing we can look at how best to move forward (whether it's a bug, whether we can offer an enhancement around it, and whether backporting to earlier branches is an option, etc)

Thanks
Isomorphic Software

[Blama]

Hi Isomorphic,

I'm using the exact same test code from my post you linked. As version I'm using SNAPSHOT_v10.1d_2015-04-01.

I added the following DMI to DataSource employees2 in order to show the effect even better:

Employees2.java:

package com.smartgwt.sample.server.listener;

import javax.servlet.http.HttpServletRequest;

import com.isomorphic.datasource.DSRequest;
import com.isomorphic.datasource.DSResponse;

public class Employees2 {

	public DSResponse fetch(DSRequest request, HttpServletRequest servletRequest) throws Exception {
		[B]Thread.sleep(4000);[/B]
		return request.execute();
	}
}

employees2.ds.xml addition:

<serverObject lookupStyle="new" className="com.smartgwt.sample.server.listener.Employees2" /

I run the sample in GWT Development Mode, but it is also occurring in compiled mode.

After startup do the following steps:

1. Click "Employees" and wait for the ListGrid to load
2. Double-Click an employee to show the Window with the DynamicForm
3. See how both, SelectItem and ComboBoxItem (this is different to my report) show "4" for a short time before they show "Charles Madigan".
   (Before I reported "For ComboBoxItems, the string "Loading" is displayed, instead." This is not true for 5.1d (but the arrow from the ComboBoxItem is disabled for a short time, most likely 4.1p displays "Loading" during that time, effectively hiding the ID-value of "4").

Please see the attached screenshot "During_Load.png".

Basically my old report ends here.

While testing now, I also noted that the requests fired for the FormItems differ. A double click results in 4 requests (1x DynamicForm (does not matter here), 1x ComboBoxItem (ID-lookup), 2x SelectItem (rows 0-75 and rows 75-150).
I don't know if this difference between ID-lookup and all-data is on purpose, but if it is, why don't request all data at once?
Please see the attached screenshot "DeveloperConsole.png".


Also, in the Developer Console in column "Time sent", a time or a datetime would be more useful than a date. I'll open a separate thread on this.

Best regards,
Blama

[Isomorphic]

Thanks for the clarification and the additional code.
We do see this behavior. We're looking into whether we can make a framework change to have the "loading" message display instead of the underlying data value for SelectItems. We'll follow up when we have more information on this. Note that depending on how involved the change is this may not be one we can easily back-port to older branches.

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

that's great. As I'm on 5.0p now and I don't think that I will switch to 4.1p again, I'm fine with 5.0p (or perhaps 5.1d).
But please note that the "loading" message was already being displayed in 4.1p, at least for ComboBoxItems!

Best regards,
Blama

[Isomorphic]

We've made some changes which we believe will address this in both the 5.0p and 5.1d branches.
Please try the next nightly build dated April 8 or above, and let us know if the problem persists.

Thanks and Regards
Isomorphic Software

[Blama]

Hello Isomorphic,

thanks for this change which hides the ID-value for me in the current 5.0p (v10.0p_2015-04-08) (in both my application and the sample). This really is an improvement to the way it was before.

Please note that the design while loading is still different for ComboBoxItems and SelectItems (see attached screenshot of the sample from post #8).
This is very minor, but noticeable even in compiled mode (Simplicity skin (should not be important), without the Thread.sleep()-DMI of course).

Best regards,
Blama