Enum-based ComboBox?

[intrinsical]

Hi,

I'm still very new to GXT so please forgive me if this is a stupid question. I have the following enum:

public enum UserType {
   Guest, User, Admin
}

I am trying to figure out how I can get a ComboBox to use this UserType's enum strings in its dropdown selection box, but store have the ComboBox update values based on the UserType's ordinal/integer value. I would appreciate it if anyone can provide me with directions or sample code.

[sven]

You have to convert the enum to use ModelData

[sdc]

Could it work with the @BEAN annotation + BeanModelMarker interface ?

[sven]

No, as this are two different things

[Colin Alworth]

My quick and dirty solution would be to use a simple modeldata as sven suggested, then use a custom Converter class to transfer back and forth.

Try this as a model object - this assumes that the toString() method of the enum has been overridden to display something useful (you aren't just displaying the PascalCased words on your otherwise pretty UI are you? Alternatively, you could make the constructor take an additional String param if you like...

public class EnumWrapper<E extends Enum<E>> extends BaseModelData {
    public EnumWrapper(E enumValue) {
        set("enum", enumValue);
        set("value", enumValue.toString());
    }
}

Then the Converter subclass looks something like this:

public class EnumConverter<E> extends Converter {
    public Object convertFieldValue(Object value) {
        return new EnumWrapper<E>((E)value);
    }
    public Object convertModelValue(Object value) {
        return ((EnumWrapper)value).get("enum");
    }
}

I think this is a good question, one which I will need answered for myself in the coming weeks, so if anyone has good/bad luck with this approach or finds another one, please share!



FWIW, I am find a lot of cases where a Converter class is essential to get many faucets of GXT working well. They are ugly to have to patch in, as you only want a single instance of each one, and Java's syntax makes them rather verbose - at least 6 lines of code before you even start adding custom code to the thing... Anyone have better ideas on how some of this could be implemented?

I am aware that it is a big deal to get the ComboBox working well, especially if you want it to contain complex data, but this whole idea of using a Map<String, Object> (i.e. ModelData) feels like you are trying to write Javascript components in Java. And while yes, it will all be compiled to Javascript in the end, the entire point of using Java is to stay far away from Javascript ...

[jadrake75]

This is exactly what I have done in my application. It would be nice to perhaps have an EnumConverter OOTB with GXT. One exception is I would say there should be a public method "toDisplayString( Enum val )" which can convert the enum (or internal name) of the selection to a proper display string using the localized resources. By default this could simply do a val.toString( ) unless implemented.

[intrinsical]

I agree.

I have been evaluating Gxt for the past month and while I feel that Gxt is a nice library, it suffers from little pieces of complexities like this that makes it not only frustrating to use, but also seriously slows down development speed. I'm spending more time figuring out how to do get Gxt to do what I want than actually developing my web app.

Btw, this is the first time I've even heard about Converters. How would I plug this converter into the grid editor?

[Colin Alworth]

Converters are attached to FieldBinding objects, and are only used when binding occurs. While using the CellEditor class, it appears you could subclass it and override the preProcessValue(Object) and postProcessValue(Object) methods to act like a Converter Object.

In my opinion, the Converter object should be pluggable into the CellEditor using those methods, much like the FieldBinding object accepts an optional Converter. Not doing so is rather inconsistent...

But aside from these inconsistencies, I have to say that using GWT (and the GXT library) yields slightly more rapid initial development, but also far faster subsequent development. It isn't entirely due to _using_ the language, but more to the assurances that Java gives you in terms of types, and so the nice refactoring tricks you can do. Eclipse's 'find all references' and Javadoc have made my work with these libraries much simplier than any AJAX project that I have undertaken before.

I agree that GXT is not fully mature yet, but then again, this is a milestone release. The changes discussed in this thread are API breaking, so I don't know if we will get them with the 2.0 release (can a dev comment on this?), but at least the Converter+CellEditor issue seems to be a pretty obvious one, with very little additional code required. I'm not sure I agree that it actually slows down development time, but it does have a long ways to go.

[bigmountainben]

You can also use the BeanModelMarker method:

@BeanModelMarker.BEAN(MyEnum.class)
public class MyEnumModel implements BeanModelMarker { }

And then you can use the BeanModel in your combo box. Add a getDescription to your Enum:

Enum UserType {

   User("A User"),
   Admin("An Admin");

   String description;

   UserType(String desc) { this.description = desc; }
  
   private String getDescription() { return description; }
}

And set the combo box's displayField to be 'description'.

comboBox.getValue().getBean() will get you back the Enum.

Ben

[Colin Alworth]

Clever - I haven't done any with the bean code, so its all sorta magic in my book still ;-). My next project is going to have to include some experimentation with these things.

How about working with GWT's localizable constant code to make the interface change text based on language? By this pattern, the Enum is written in the server code, so it can't interact with the GWT.create command for injecting strings...

Thanks for the cool suggestion - any thoughts?