Component should implements HasEnabled ?

[hermann.rangamana]

Hello,

I think Component class would benefit for implementing HasEnabled interface (there'd be no API change, since Component already has setEnabled(boolean)/isEnabled). The benefit is that when i use the enabled/disabled feature on a view of my MVP, i would declare HasEnabled in my view, and just return the component in the view implementation. For now, i need to wrap the component in a anonymous inner class of type HasEnabled and forward the call to setEnabled/isEnabled into the component's setEnabled/isEnabled.
As an example :
My view

public interface View 
{
    HasEnabled myOkButton();
    
    interface Presenter 
    {
    }
}

For the view implementation, i need to do the following

public class ViewImpl implements View
{
    private TextButton okButton;
    
    @Override
    public HasEnabled myOkButton()
    {
        return new HasEnabled()
        {
            @Override
            public void setEnabled(boolean enabled)
            {
                okButton.setEnabled(enabled);
            }
            
            @Override
            public boolean isEnabled()
            {
                return okButton.isEnabled();
            }
        };
    }
}

If Component implemented HasEnabled interface, my view implementation would be like the following, which is much much clearer ...

public class ViewImpl implements View
{
    private TextButton okButton;
    
    @Override
    public HasEnabled myOkButton()
    {
        return okButton;
    }
}

Thanks

Hermann

[WesleyMoy]

Thanks for the report. I've filed an API review ticket and will update this thread with any decision or changes we make. Like you said, Component already implements these methods, so this change seems to make sense at first glance.

[WesleyMoy]

I've had a chance to review this and have committed the change to SVN as r2619.

[WesleyMoy]

The fix for this shortcoming has been included in the public release of Sencha GXT 3.0.0. You should be able to observe this change in our source. Although we're confident that this issue has been resolved, please reply here (or start a new bug thread linking to this one) if you have any issues with this change.