Hybrid View

    Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-2496 in a recent build.
  1. #1
    Sencha Premium Member
    Join Date
    Dec 2011
    Posts
    34
    Vote Rating
    0
    MarcT is on a distinguished road

      0  

    Default TriggerFieldDefaultAppearance keeps too much private

    TriggerFieldDefaultAppearance keeps too much private


    Required Information

    Version(s) of Ext GWT
    GXT 3.0.1

    Browser versions and OS
    (and desktop environment, if applicable)
    • Chrome 22, Win7

    Virtual Machine
    No

    Description
    We are making our own theme. We have subclassed TriggerFieldDefaultAppearance, but it would be a lot easier if more was protected instead of private. Specifically, the member fields resources and style, and the helper function renderInput(). We are overriding render(), and all 3 of those are used in render. Currently, we have to shadow them, including copy-pasting the renderIntput function into our subclass. Are we doing something unintended here, or should those fields/function be made protected instead?

    Most "DefaultAppearance" classes use protected for members and helpers and are easy to override, so I hope this was just an oversight.

    Run mode
    both

    Steps to reproduce the problem
    1. Try to subclass TriggerFieldDefaultAppearance
    2. Override render(), try to use resources and style, or call renderInput

    Expected result
    Compiles

    Actual result
    Fails to compile because members are private rather than protected.

    Test case
    Code:
    package airmarshal.client.theme.lux.field;
    import com.google.gwt.core.client.GWT;
    import com.google.gwt.safehtml.shared.SafeHtmlBuilder;
    import com.sencha.gxt.cell.core.client.form.FieldCell.FieldAppearanceOptions;
    import com.sencha.gxt.theme.base.client.field.TriggerFieldDefaultAppearance;
    public class LuxTriggerFieldAppearance extends TriggerFieldDefaultAppearance {
    
      public LuxTriggerFieldAppearance() {
        this(GWT.<TriggerFieldResources> create(TriggerFieldResources.class));
      }
    
      public LuxTriggerFieldAppearance(TriggerFieldResources resources) {
        super(resources);
      }
    
      @Override
      public void render(SafeHtmlBuilder sb, String value, FieldAppearanceOptions options) {
    
        SafeStyles inputStyles = SafeStylesUtils.fromTrustedString("width:" + width + "px;");
        sb.appendHtmlConstant("<div class='" + style.trigger() + "' />");
        sb.renderInput(sb, value, inputStyles, options);
      }
    }
    Possible fix
    Make private fields and methods protected.

  2. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    (Post apparently failed, but with no error message, trying again)

    Thanks - you make a good point about this. I've just finished a large audit of the use of appearances in widgets (I think you filed this bug earlier) and will have it merged in soon, and this looks like a new target for improvement.

    In a pinch, remember that you can write a JSNI getter method for those private fields. Additionally, you can use the constructor as an opportunity to get a reference to that clientbundle and cssResources, though doing so creates another field, which would be good to avoid.

    We'll be marking them always as final in an attempt to better communicate that the default implementations are designed to be read, not written, and to be as stateless as possible, as both of these will allow the compiler to do a better job with removing any extra abstractions and writing out faster compiled code. We with need public or protected getters for each of those fields, or to modify those fields to be more readable from subclasses.

  3. #3
    Sencha Premium Member
    Join Date
    Dec 2011
    Posts
    34
    Vote Rating
    0
    MarcT is on a distinguished road

      0  

    Default


    Thanks, Colin, I've been using both the workarounds you suggested.

    Marking those fields final is just fine, but in order to do common things like override render(), they need to be protected rather than private. Most of them are "protected final" already, which just makes the ones that are private that much more glaring. I appreciate you recognizing this is a "consistency sweep" kind of bug and not just an isolated incident!