<Swing Dev> 6303622: Generics: JComboBox: get/setSelectedItem(Object)

[Pavel Porvatov]

Hi Ricardo,
> In the example I attached in the previous thread:
> - Generified editable combobox was supported *if* the generic class 
> had a constructor: new XXX(String s). It is easy to modify it to 
> accept an empty contructor plus a setter method setName(String s) or 
> whatever
It looks too tricky to use such generification. Just imagine if the 
java.util.List class was generified in the same way....

> - That solution used ComboBoxModelExtended<I>, so the model was 
> generified. I dont see any advantage in defining <? extends E> 
> instead. Could you specify them?
Sure. Lets an application uses a database and most of tables in this DB 
has a primary key. We'd like to use JComboBox to select values from some 
tables. In described situation we could have a base class for table records:
    public static class DbRecord {
        private long id;

        public long getId() {
            return id;
        }

        public void setId(long id) {
            this.id = id;
        }
    }

    public static class Employee extends DbRecord {
        ...
    }

    public static class Department extends DbRecord {
        ...
    }

After that you can set model like this:
    ComboBoxModel<Employee> employeeComboBoxModel;
    ComboBoxModel<Department> departmentComboBoxModel;

    JComboBox<DbRecord> comboBox = new JComboBox<DbRecord>();

    comboBox.setModel(employeeComboBoxModel);
    comboBox.setModel(departmentComboBoxModel);

In this example we are interested only in id of a selected record. If a 
user types a new value in an editable ComboBox then a new record is 
created in a suitable table.
>
> Besides I dont see the point in creating a read-write combobox where 
> the items are not either specific objects (that contains the special 
> method/contructor) or strings.
>
> I see more advantages to generifying them than not.
See my example above. Try to implement the same functionality with your 
generification and you'll see that it's harder to done.

Regards, Pavel
>
> --
> Ricardo
>
>
> On Tue, Dec 15, 2009 at 5:36 PM, Pavel Porvatov 
> <Pavel.Porvatov at sun.com <mailto:Pavel.Porvatov at sun.com>> wrote:
>
>     Hi Florian,
>
>         Hi Pavel,
>
>         I start here a new thread for the "get/setSelectedItem(Object)
>         methods of JComboBox and ComboBoxModel" discussion.
>
>         After further analysis of the code and your sample application
>         I think we can and should generify the
>         get/setSelectedItem(Object) methods of JComboBox and
>         ComboBoxModel.
>
>         Yes, the Javadoc says that JComboBox/ ComboBoxModel supports
>         selected values not managed by the underlying list model. But
>         this does not prohibit to optionally limit the type by using
>         generics und thus to increase type safety.
>         If you need to allow other types from editor than the ones in
>         the list model, you still can use:
>         JComboBox<Object> (or JComboBox, but this is not recommended)
>
>         So there should be no backward compatibility problem.
>
>         When using a JComboBox, usually you are interested in the
>         selected value and since you want to do something with it you
>         expect it to have some specific type. So if we generify the
>         get/setSelectedItem(Object), you can profit from that in most
>         cases.
>
>         Even in cases where you have an initial text in an editable
>         combo box you can profit from that, if you use a "null" value
>         as the selected value, which according to the API is used for
>         "no selection", and a custom editor for rendering that null
>         value. (see attachement; I used your sample application as a
>         base; delete the text to set the selected value to null again).
>          
>
>     I agree that generification of the get/setSelectedItem(Object)
>     methods will be useful. But than we will have another
>     generification disadvantage. I tried to summarize benefits of two
>     solutions below.
>
>     *Generified get/setSelectedItem:*
>     a. Simplified usage read-only comboboxes or non read-only
>     comboboxes with special editor
>
>     b. Disadvantage: if you use generified editable combobox *without*
>     editor then ClassCastException will be thrown in runtime
>
>     *Not generified get/setSelectedItem:*
>     a. A possibility to generify the javax.swing.JComboBox#dataModel
>     as ComboBoxModel<? extends E>. It give us more flexible usage of
>     ComboBox:
>
>     ComboBoxModel<Integer> cbModel = ....;
>     JComboBox<Number> cb = new JComboBox<Number>(cbModel);
>
>     Note that it's the main benefit that forced us to suggest not
>     generified methods
>
>     b. To use not read-only combobox with generified model
>
>
>     So I believe that not generified get/setSelectedItem methods give
>     more benefits and less disadvantages.
>     What do you think about that?
>
>     Regards, Pavel
>
>
>
>
> -- 
> Chipu