Results 1 to 3 of 3

Thread: TriggerFieldDefaultAppearance keeps too much private

Hybrid View

Previous Post Previous Post   Next Post Next Post
    Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-2496 in 3.0.3.
  1. #1
    Sencha Premium Member
    Join Date
    Dec 2011
    Vote Rating

    Default 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

    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

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

    Expected result

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

    Test case
    package airmarshal.client.theme.lux.field;
    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) {
      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 User
    Join Date
    Feb 2009
    Vote Rating


    (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
    Vote Rating


    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!

Tags for this Thread

Posting Permissions

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