Results 1 to 10 of 25

Thread: Enum-based ComboBox?

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Question Enum-based ComboBox?

    Hi,

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

    Code:
    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.

  2. #2
    Sencha Premium Member
    Join Date
    Sep 2007
    Posts
    13,976

    Default

    You have to convert the enum to use ModelData

  3. #3
    Ext User
    Join Date
    Jun 2008
    Posts
    365

    Default

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

  4. #4
    Sencha Premium Member
    Join Date
    Sep 2007
    Posts
    13,976

    Default

    No, as this are two different things

  5. #5
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737

    Default

    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...

    Code:
    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:

    Code:
    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 ...

  6. #6
    Ext JS Premium Member jadrake75's Avatar
    Join Date
    Sep 2008
    Posts
    108

    Default Converter

    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.

  7. #7
    Sencha User
    Join Date
    Jun 2009
    Posts
    47

    Question

    Quote Originally Posted by Colin Alworth View Post
    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...

    Code:
    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:

    Code:
    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 ...
    I tried this approach with the classes you provided but the EnumConverter doesn't even compile. Can you maybe provide me with a working example of the code and how to use it in practice?

  8. #8

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •