change occapacity of disabled field

[gishmo]

What is the best way to change the occapacity of disable fields for the whole application in GXT 3?

[darrellmeyer]

We have modified CommonStyles to be Appearance based. With these changes, you can substitute your own implementation with your custom styles. You would define your own rule similar to this:

<replace-with class="com.sencha.gxt.core.client.resources.CommonStyles.CommonStylesDefaultAppearance">
  <when-type-is class="com.sencha.gxt.core.client.resources.CommonStyles.CommonStylesAppearance" />
</replace-with>

Changes are in SVN.

[billsalvucci]

You didn't give CommonStylesDefaultAppearance a constructor that takes a ClientBundle and you made the bundle and style properties private

private final CommonDefaultResources bundle;
    private final Styles styles;
    
    public CommonStylesDefaultAppearance() {
      bundle = GWT.create(CommonDefaultResources.class);
      styles = bundle.styles();
    }

Normally, I would extend the default appearance using a default constructor that calls super with my ClientBundle

public interface Resources extends CommonDefaultResources {

          ImageResource shim();

          @Override
          @Source("CommonStyles.css")
          Styles styles();

        }

        public interface Styles extends CommonDefaultStyles {

        }
        
        public MyStylesAppearance() {
            super(GWT.<Resources> create(Resources.class));
        }

and I can't work around by doing

public MyStylesAppearance() {
            bundle = GWT.create(CommonDefaultResources.class);
            styles = bundle.styles();
          }

because bundle and styles are private.

[Colin Alworth]

While that is true, the CommonStylesAppearance interface is simple enough that you shouldn't be extending the default implementation - just implement your own, perhaps extending the ClientBundle or declaring your own. Then declare that in your module as the replacement for CommonStylesAppearance, as Darrell indicated in his post.

In cases where there is an abstract base appearance, there is some logic being provided that often would be shared by most real implementations of that appearance. There is no such logic here, so using the base class gains you nothing.