Results 1 to 10 of 10

Thread: [1.2.1] MultiField shouldn't extend Field<F>

  1. #1
    Ext User
    Join Date
    Jan 2009
    Location
    Luxembourg
    Posts
    13

    Default [1.2.1] MultiField shouldn't extend Field<F>


  2. #2
    Ext User
    Join Date
    Jan 2009
    Location
    Luxembourg
    Posts
    13

    Default

    Waiting for an official answer.. what's your opinion? Does anyone even use MultiField?

  3. #3

    Default

    Quote Originally Posted by ogerardin View Post
    Waiting for an official answer.. what's your opinion? Does anyone even use MultiField?
    I use MultiField<CheckBox> by extending from it so I can override the public CheckBox getValue() method which has to return CheckBox. It should return a Set of CheckBox but the generic nature prevents that.

    This is my alternative,

    Code:
    public class UecCheckBoxGroup extends MultiField<CheckBox> {
    
           /**
            * There is not sensible CheckBox to return
    	 */
    	 @Override
    	 public CheckBox getValue() {
    	 	throw new UnsupportedOperationException("UecCheckBoxGroup.getValue is meaningless");
    	}
    
    	/**
    	 * @return The choices
    	  */
    	  public ChoiceSet getChoiceSet() {
    	  	 Set<Choice> choices = new HashSet<Choice>();
    	 	     for (CheckBox cb : fields) {
    		     	   choices.add(new Choice(cb.getName(), cb.getValue()));
    		   }
    		return new ChoiceSet(choices);
    	}
    }
    Although this is imperfect it works for me.

  4. #4
    Ext User
    Join Date
    Jan 2009
    Location
    Luxembourg
    Posts
    13

    Default

    Quote Originally Posted by janekdb View Post
    I use MultiField<CheckBox> by extending from it so I can override the public CheckBox getValue() method which has to return CheckBox.
    This is fine for you because you're not using FieldBindings, so you can call getChoiceSet() instead of getValue(). The default FieldBinding implementation uses getValue() and setValue(), which are supposed to return/take a type that can be bound to a property of the Model, and obviously Field is not in this case...

    So why should getValue() of MultiField return a Field?? This might be valid for very specific use cases, but for the sake of genericity I think the data type of the MultiField should be distinct from the Field type it manages. So I suggested changing the declaration to:
    Code:
    public class MultiField<F extends Field, D> extends Field<D>
    you could then declare for example

    Code:
    public MyMultiField extends MultiField<TexField, String>
    The TextField parameter would constrain Fields added to the MultiField to be TextFields, and the String parameter would constrain getValue()/setValue() to return/take a String. It would then be easy to override getValue()/setValue() to do something useful, which makes it possible to use the default Field bindings to bind the MultiField to a model's property.

    Now I have to use an explicit FieldBinding subclass that overrides updateField() and updateModel() to call something else than setValue()/getValue().

  5. #5

    Default

    Yes, my example was too simple. I see your point. It would work for me.

  6. #6
    Sencha Premium Member
    Join Date
    Sep 2007
    Posts
    13,976

    Default

    We cant do this change in any 1.2 branche as it would brake the api. For the upcomming 2.0 release it can be possible and will be concidered as a change.

  7. #7
    Ext User
    Join Date
    Jan 2009
    Location
    Luxembourg
    Posts
    13

    Default

    Quote Originally Posted by sven View Post
    We cant do this change in any 1.2 branche as it would brake the api. For the upcomming 2.0 release it can be possible and will be concidered as a change.
    Fine. Meanwhile I can live with my custom FieldBinding, but being able to use autobind would be better...

  8. #8

    Exclamation

    I disagree. If I understood well your suggestion we could be only to put one type of Fields. I use MultiField to mix Fields. I put inside it: ComboBoxes, TextFields, NumberFields etc. using FieldBindings It's fine for me to use it without setting Field's type and I think, that present implementation is OK - it is more flexible. I just set binding not on MultiField, but on every Field. If you want to use only one type of Fields and FieldBindings you can still do it. Just set the binding not on MultiField but on every Field. As far as I am concerned MultiField is the only way to obtain Layout that has Fields one by another ( shown here: http://www.extjs.com/forum/showthrea...ght=MultiField ). Don't take it from us until you provide layout like this one!

    Here you have sample code:
    Bindings bindings = new Bindings();
    MultiField<Field> fieldSecondRow = new MultiField<Field>();
    fieldSecondRow.setWidth(650);
    fieldSecondRow.setOrientation(Orientation.HORIZONTAL);
    fieldSecondRow.setSpacing(15);
    DateField date= new DateField();
    date.setReadOnly(true);
    date.setWidth(160);
    bindings.addFieldBinding(new FieldBinding(date,"col1"));
    fieldSecondRow.add(nominalOrderDate);
    DateField secondDate= new DateField();
    secondDate.setReadOnly(true);
    secondDate.setWidth(150);
    bindings.addFieldBinding(new FieldBinding(secondDate,"col2"));
    fieldSecondRow.add(transformationDate);
    NumberField number = new NumberField();
    number.setReadOnly(true);
    number.setWidth(150);
    bindings.addFieldBinding(new FieldBinding(number,"col3"));
    fieldSecondRow.add(cancelDate);
    TextField<String> text1= new TextField<String>();
    text1.setReadOnly(true);
    text1.setWidth(120);
    bindings.addFieldBinding(new FieldBinding(text1,"col4"));
    fieldSecondRow.add(taxType);
    Last edited by mwojciechowski; 26 Jan 2009 at 1:03 AM. Reason: Adding sample code

  9. #9
    Ext User
    Join Date
    Jan 2009
    Location
    Luxembourg
    Posts
    13

    Default

    Quote Originally Posted by mwojciechowski View Post
    I disagree. If I understood well your suggestion we could be only to put one type of Fields.
    I'm sorry but you misunderstood. My suggestion doesn't remove anything, it just adds a second generic parameter to the MultiField class which would be used to specify the data type behind the MultiField. This only affects the profile of setValue() and getValue(), nothing else has to change.

    If you want to use the same semantics as today, just repeat Field as data type, e.g.:

    Code:
    class MyMultiField extends MultiField<Field, Field>

  10. #10

    Smile

    Ok... I hope you're right...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •