Better/more use of generics

[zaccret]

There are some places where the use of generics can cause warnings with javac or eclipse compiler (and require us to add @SuppressWarnings). Maybe this is obvious to you, Darell, but maybe we can help in identify the places.

For now, I see these places :
- In Controller class. When we extend Controller, we get a warning on handleEvent(AppEvent) where AppEvent is a raw type and should be parameterized.

public abstract void handleEvent(AppEvent event); could be
public abstract void handleEvent(AppEvent<?> event);- In BaseModel. When I write a class extending BaseModel, I get those warnings in javac output concerning set and remove method
warning: remove(java.lang.String) in com.extjs.gxt.ui.client.data.BaseModel implements <X>remove(java.lang.String) in com.extjs.gxt.ui.client.data.ModelData; return type requires unchecked conversion
[javac] found : java.lang.Object
[javac] required: X
[javac] public class DefaultBaseModel extends BaseModel { So
public Object set(String name, Object value) {
Object oldValue = super.set(name, value);
notifyPropertyChanged(name, value, oldValue);
return oldValue;
}
...
public Object remove(String name) {
if (map.containsKey(name)) {
Object oldValue = super.remove(name);
notifyPropertyChanged(name, null, oldValue);
return oldValue;
}
return null;
}
could be
public <X> X set(String name, X value) {
X oldValue = super.set(name, value);
notifyPropertyChanged(name, value, oldValue);
return oldValue;
}
...
public <X> X remove(String name) {
if (map.containsKey(name)) {
X oldValue = super.remove(name);
notifyPropertyChanged(name, null, oldValue);
return oldValue;
}
return null;
}
Tell us if that helps, Darell, or if you already know these small issues.

[jraue]

Please see also the thread http://extjs.com/forum/showthread.php?t=36174 for this topic.

[zaccret]

In ComboBox :

public void setModelStringProvider(ModelStringProvider modelStringProvider)
public ModelStringProvider getModelStringProvider()could be

public void setModelStringProvider(ModelStringProvider<Data> modelStringProvider)
public ModelStringProvider<Data> getModelStringProvider()Also get/set for propertyEditor are inconsistent. You could add a parameter <Editor extends PropertyEditor<Data>> in Field and ComboBox could extends Field<ModelPropertyEditor<Data>> or you could override setPropertyEditor.

[zaccret]

In Menu class :

public class Menu extends Container<MenuItem> could be
public class Menu<T extends MenuItem> extends Container<T>It would be useful to create custom widgets with type-safe menu items.

[darrellmeyer]

could be
public void setModelStringProvider(ModelStringProvider<Data> modelStringProvider)
public ModelStringProvider<Data> getModelStringProvider()
Done.

Also get/set for propertyEditor are inconsistent. You could add a parameter <Editor extends PropertyEditor<Data>> in Field and ComboBox could extends Field<ModelPropertyEditor<Data>> or you could override setPropertyEditor.
I dont want to add propertyeditor to the class types and you cannot override the method. I added an assert in combo that checks the editor type.

It would be useful to create custom widgets with type-safe menu items.
Menu is a generic container, so it does not make much sense to make it generic as most of the time you will be mixing types. You will need to cast. This is the same behavior as other containers such as LayoutContainer.

[zaccret]

Done.
Thanks. :)


I dont want to add propertyeditor to the class types and you cannot override the method. I added an assert in combo that checks the editor type.You're right, sorry, you cannot override the set method. That's why a new type on the (abstract) Field class would have been nice ;)


Menu is a generic container, so it does not make much sense to make it generic as most of the time you will be mixing types. You will need to cast. This is the same behavior as other containers such as LayoutContainer.Right about LayoutContainer but I see that ScrollContainer class has a <T extends Component> type. Why not the same for Menu and we would use MenuItem if mixing types ? However you're right, it depends on what is the most common use case : mixing types or not in a Menu.

What about handleEvent in Controller and View classes (cause warnings) ?
public abstract void handleEvent(AppEvent<?> event);And set and remove in BaseModel (also cause warnings) ?

public <X> X set(String name, X value) {...}
...
public <X> X remove(String name) {...}

[eugenparaschiv]

When dealing with events, some methods could be defined in a different, more flexible way with generics. For example:
the Component class has the method:
public void onComponentEvent(ComponentEvent ce)
this should be
public <E extends ComponentEvent> void onComponent( E event )

and then in field, it is now:
public void onComponentEvent(ComponentEvent ce)
super.onComponentEvent(ce); //no point, does absolutely nothing
FieldEvent fe = new FieldEvent(this);
fe.event = ce.event;
so still the same signature, which means that the code does not benefit from good type checking; what is more, the event has to be recreated so that it can be used as a field event. All of these problems would go away when using generics:
public <F extends FieldEvent> void onComponent(F event)
then the event could simply be used as a FieldEvent (because it is a field event) and no other duplicate event would be required. And, we would have strong type checking on top.
Any thoughts on this?
Cheeres.
Eugen.