ListGrid Enum data type order of values

[mgreenberg]

Hello Isomorphic,

We are using Smart Client v8.3p_2013-07-18/Pro Deployment. We have a data source that has a field 'aStatusField' of type enum. This field is an editable field in the ListGrid that displays a drop-down with the enum values from our Java enum com.mycompany.StatusEnum. The code for StatusEnum is copied below too. I wanted to populate the status column drop-down values in the order they are defined in the enum - "Unresolved," "In Progress," and "Resolved." However, they get listed in the order "Resolved," "Unresolved," "In Progress." Why do they get listed this way? Is there a way to define the order they are listed in the drop-down?

Thanks.

<DataSource ID="MyPageDS" serverConstructor="spring:myPageDataSource"
	schemaBean="com.mycompany.MyPage" validateRelatedRecords="true">
	<fields>
		<field primaryKey="true" name="id" title="ID" type="sequence" />
		<field name="additionalCriteria1Id" type="integer" />
		<field name="additionalCriteria2Id" type="integer" />
		<field name="additionalCriteria3Id" type="integer" />
		<field name="additionalCriteria4Id" type="integer" />
		<field name="aTextField" type="text" />
		<field name="aDateField" type="datetime" />
		<field name="anotherTextField" type="text" />
		<field name="aStatusField" type="enum" valueMapEnum="com.mycompany.StatusEnum" />
		<field name="mostRecentNote" type="MyPageNotesDS" />
		<field name="comments" type="any" />
	</fields>

</DataSource>

public enum StatusEnum {

	Unresolved("Unresolved", 1),
	InProgress("In Progress", 2),
	Resolved("Resolved", 3);

	private String value;

	private int order;

	private StatusEnum(final String value, final int order) {

		this.value = value;
		this.order = order;
	}

	public int toInt() {

		return order;
	}
}

[sabaka]

This is fixed now. Changes will be in next nightly build.

[mgreenberg]

Thanks for your response. Actually, I changed the data type to be intEnum instead of enum so that the status is displayed in the right order in the drop-down and also, so that I can sort the column based on the enum ordinal value (which doesn't work currently unfortunately and posted another forum post at http://forums.smartclient.com/showthread.php?p=108595#post108595).

Now they display in the right order as defined in the enum (Unresolved, In Progress and Resolved), however, I am noticing two things in the editable drop-down (see attached screenshot).
(1) The value for that field is duplicated in that drop-down and then the values from the enum are listed as separate options.
(2) The mapped string values for the enum are aligned to the right instead of to the left.

Any input would really be appreciated. Thanks again!

[Isomorphic]

1. most likely, you have code that is providing a value for the field as a String but the type is now int, so your value is being treated as an extra value

2. we'll check on this

[mgreenberg]

Thanks for checking on (2). Regarding (1), I have a field of type "StatusEnum" in the java bean that is returned for each item in the list of records. I see in the RPC response in the console aStatusField:"Resolved" as an example, so you are right and it is returning a string. Is there some sort of property in Smart Client that I can set to return the ordinal (int) value for the enum instead of the string? Or am I supposed to have a separate getter in my java bean for returning the int value for the enum?

[Isomorphic]

You have choices as to what approach is used - see DataSource.enumTranslateStrategy.

[mgreenberg]

Thanks for (1) - that was it. I set the enumTranslationStrategy to ordinal and that fixed it. I remember seeing that in the documentation recently.

[Isomorphic]

Does that explain the problem encountered in your other thread after switching to intEnum? Please take a look and update us.

[mgreenberg]

Yep! That seemed to do the trick. I will reply in the other forum post too.
I will wait on item (2) here but my two main concerns so far seem to be covered.

Thanks again! :)

[mgreenberg]

Hello again, Isomorphic.

I am using enumTranslateStrategy set to "ordinal" as you suggested which works well for the most part but I am noticing a related issue.

In our ListGrid with the MyPageDS data source, other than the editable ListGrid field 'StatusEnum', we also have another field 'Notes' that gets updated whenever a new note is added for that record. As an expansion component for each row, we show a ListGrid listing all notes for that record (MyNotesDS). Within the expansion component, we also have a button 'Add Note' for that row that updates the Notes list grid and also updates the Notes column in the MyPageDS ListGrid with the latest note.

In our backend, in executeAdd() on MyNotesDS, we are doing an update on MyPageDS and call addRelatedUpdate on MyNotesDS. It seems that when the operation type is set to "update" on MyPageDS, I am noticing issue (1) again where the value for that field is duplicated in the drop-down, even with enumTranslateStrategy set to "ordinal". It works fine with a "fetch" as I already mentioned but enumTranslateStrategy seems to be ignored for an "update" on the DS.

Am I missing something? Below is the code in our executeAdd method for our NotesDS:

@Override
public DSResponse executeAdd(final DSRequest dsRequest) {

	Note note = // Insert note to DB

	MyPageItem pageItem = // find Page Item using DAO

	DSResponse noteDsResponse = new DSResponse(note, DSResponse.STATUS_SUCCESS);

	DSResponse pageDsResponse = new DSResponse(pageItem, DSResponse.STATUS_SUCCESS);
	pageDsResponse.setOperationType("update");

	DataSource pageDataSource;

	try {
		pageDataSource = dsRequest.getRPCManager().getDataSource("MyPageDS");
	} catch (final Exception e) {
		throw new RuntimeException(e);
	}

	pageDsResponse.setDataSource(pageDataSource);

	noteDsResponse.addRelatedUpdate(pageDsResponse);

	return noteDsResponse;
}

[Isomorphic]

Take a look in the RPC tab for the response where you use addRelatedUpdates(), the related update should be visible. Are you see that the String value was used here instead of the ordinal?

Note, just for clarity, we actually didn't particularly recommend switching to this strategy; there are tradeoffs either way (more bytes on the wire vs data having clearer meaning when inspected).

[mgreenberg]

I unfortunately don't see anything in the RPC tab for the response, just the DSRequest. I have Track RPCs checked. Is there any other way I can debug into this or anything else I can try?
Oh okay, if there are any other options that would be better for our use-case, we are open to suggestions.

[Isomorphic]

That's very strange that the RPC tab would be empty, but you can capture similar information using Firebug or any similar tool to look at the HTTP response. What it contains is basically JSON.

[mgreenberg]

Yea, responses don't seem to show up for adds but show up for fetches. Below is the JSON when I just introspect the network responses in Chrome. Looks like the status field is sent as a string instead of the ordinal 0.

//isc_RPCResponseStart-->[{data:{....,note:"Test Note"},invalidateCache:false,isDSResponse:true,operationType:"add",queueStatus:0,relatedUpdates:[{dataSource:"MyPageDS",isDSResponse:true,invalidateCache:false,status:0,operationType:"update",data:{...,aStatusField:"Unresolved",...,mostRecentNote:{timestamp:new Date(1376937896469),id:1,userId:1,userName:"Jordan, William",note:"Test Note"},...,notes:[timestamp:new Date(1376937896469),id:1,userId:1,userName:"Jordan, William",note:"Test Note"]}}],status:0}]//isc_RPCResponseEnd

[Isomorphic]

OK, we'll check that out as a possible bug - it may be that your declared DataSource.enumTranslateStrategy is not being automatically used for relatedUpdates.

Bigger picture, it seems like you switched to a non-default enumTranslateStrategy because you didn't want to implement correct server-side sort behavior in your custom SQL engine with enums being delivered as Strings.

This correct sort behavior is automatic with SQLDataSource, along with lots and lots of other stuff, and there are major new features being added all the time, so as a general recommendation we'd say you should move away from maintaining your own SQL generation engine as soon as you can.