1. #1
    Ext User
    Join Date
    Apr 2008
    Posts
    376
    Vote Rating
    0
    zaccret is on a distinguished road

      0  

    Lightbulb Better/more use of generics

    Better/more use of generics


    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.
    Code:
    public abstract void handleEvent(AppEvent event);
    could be
    Code:
    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
    Code:
    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
    Code:
      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
    Code:
        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.

  2. #2
    Ext User
    Join Date
    May 2008
    Posts
    97
    Vote Rating
    0
    jraue is on a distinguished road

      0  

    Default


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

  3. #3
    Ext User
    Join Date
    Apr 2008
    Posts
    376
    Vote Rating
    0
    zaccret is on a distinguished road

      0  

    Default


    In ComboBox :
    Code:
    public void setModelStringProvider(ModelStringProvider modelStringProvider)
    public ModelStringProvider getModelStringProvider()
    could be
    Code:
    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.

  4. #4
    Ext User
    Join Date
    Apr 2008
    Posts
    376
    Vote Rating
    0
    zaccret is on a distinguished road

      0  

    Default


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

  5. #5
    Sencha - GXT Dev Team darrellmeyer's Avatar
    Join Date
    May 2007
    Location
    Washington, DC
    Posts
    2,241
    Vote Rating
    2
    darrellmeyer is on a distinguished road

      0  

    Default


    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.

  6. #6
    Ext User
    Join Date
    Apr 2008
    Posts
    376
    Vote Rating
    0
    zaccret is on a distinguished road

      0  

    Default


    Quote Originally Posted by darrellmeyer View Post
    Done.
    Thanks.

    Code:
    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) ?
    Code:
    public abstract void handleEvent(AppEvent<?> event);
    And set and remove in BaseModel (also cause warnings) ?
    Code:
        public <X> X set(String name, X value) {...}
        ...
        public <X> X remove(String name) {...}

  7. #7
    Ext User
    Join Date
    Jul 2008
    Posts
    202
    Vote Rating
    0
    eugenparaschiv is on a distinguished road

      0  

    Default


    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.

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar