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 - That solution used ComboBoxModelExtended<I>, so the model was generified. I dont see any advantage in defining <? extends E> instead. Could you specify them?
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. -- Ricardo On Tue, Dec 15, 2009 at 5:36 PM, Pavel Porvatov <[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
