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
<[email protected] <mailto:[email protected]>> 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
