The ToolButton widget from the com.extjs.gxt.ui.client.widget.button package is quite cool, providing a handy mechanism for augmenting a ContentPanel, especially as been used as the "header" component in a GXT Window. Thus, apart from the standard "close", "minimize", and "maximize" tool-buttons, a GXT Window can be configured to have, say, a "refresh" or even a "help" tool-button, which of course can be implemented to provide the desired functionality - quite cool.

However, I find the method of instantiation for this class to be awkward, because the programmer is required to pass in strings to the constructor, strings that are some-what treated (even from the API documentation) as constants but are actually not. Aside from the imperative to always remember and employ the right string literal in a constructor call, which will lead to several unnecessary (IMHO) visits to the API documentation, there is no complie-time analysis and therefore no indication when we stray, until our code fails.

I would prefer the use of static constants, or better still, enums. A nested Enum (ToolButton.Type) or one that is externalized to, say, Style.ToolType will do a good job, so that instead of :

ToolButton helpTool = new ToolButton("x-tool-help");

we would have

ToolButton helpTool = new ToolButton(Style.ToolType.HELP);

Although this solution is more readable, cleaner, and less error prone because of the enforced compile-time checks, proponents of the AGILE development paradigm and their fans may find it kind-of verbose and eventually make a strong case against it - saying is it worth it, putting together its seeming verbosity and the refactoring required (think backwards compatibility) to re-engineer the class. So if verbosity becomes an issue, especially if we consider a nested Enum within ToolButton

ToolButton maximizeTool = new ToolButton(ToolButton.Type.MAXIMIZE);

we can re-architect our solution with a static factory method - this is actually my most preferred approach to resolving the whole problem of instantiating a ToolButton, or any other widget / class for that matter where strings that are apparently prime canditates for constants or Enums are been pased to a constructor.

public class ToolButton{

	// Turn off direct instantiation. 
	// Since the class is not final, use protected access modifier to allow subclassing.
        // this is a purist approach anyway, and is not backwards compatible, use public for that
	protected ToolButton(String style){ ... }
	protected ToolButton(String style, SelectionListener listener){ ... }

	public static ToolButton help(){
		help(new SelectionListener{
			@override public void componentSelected(IconButtonEvent evt){}
		});
	}

	public static ToolButton help(SelectionListener listener){
		return new ToolButton("x-tool-help", listener);
		// or return new ToolButton(Type.HELP, listener);
	}

}

Consequently client code is now reduced to : or its overloaded but equally succint counterpart which accepts a SelectionListener.

Besides been more concise, readable, and intuitive, our new interface promotes code usage that takes advantage of the Java compiler for error checking and optimizations.