In http://www.gwtproject.org/doc/latest/DevGuideUiBinder.html
it states that to use a widget in an uiBinder template:
they must be default instantiable; that is, they must provide a zero-argument constructor. However, there are a few ways to get around that. In addition to the
@UiFactoryand@UiField(provided = true)mechanisms described under Shared resource instances, you can mark your own widgets with the@UiConstructorannotation.
HTMLPanel fills none of these requirements and yet it can be used in an UiBinder template. How come?
Some built-in widgets within GWT have custom support in UiBinder so that they can do their work. For these cases, attributes or elements are specially handled (think about <ui:with>, <ui:field>, and of course <g:HTMLPanel>, etc) so that uibinder makes sense to use.
HTMLPanel is a special case, where it can't simply exist by implementing HasHtml and HasWidgets, since those child widgets need to be appended at a certain point inside the html structure. So, instead of working with the public API (as you found in the docs), they... cheated a bit.
The end result is something that you can't replicate in your own code without actually forking uibinder and editing it directly. This has been done in other projects, but runs the high risk of breaking when later changes to UiBinder take place, so generally should be avoided.
TL;DR: Treat HTMLPanel like a special case, which can bend the rules slightly to be more useful. In your own code, try to stick with the UiFactory/UiConstructor/UiChild annotations, setters for attributes, and implementing one of the supported interfaces for child content.