public interface AutoChildUsage
Windowcomponent and its subcomponent the
AutoChildren support four standard configuration mechanisms that can be used to customize or skin them. Note, however, that configuring AutoChildren in Smart GWT is advanced usage.
To determine which AutoChildren exist for a particular component type, search the class'
for "AutoChild" as there is a getter for each AutoChild that is supported. In the case
MultiAutoChild, the getter is
returns null) and exists only to make you aware that the MultiAutoChild exists.
The four different ways to configure AutoChildren in Smart GWT are:
FormItem.setAutoChildVisibility(String, boolean)API as appropriate is used to change this property for the named AutoChild.
To change the properties of an AutoChild of a widget, the
Canvas.setAutoChildProperties(String, FormItem) API
is used. To change the properties of an AutoChild of a form item, the
API is used. For example:
final Window myWindow = new Window(); final Layout headerProperties = new Layout(); headerProperties.setLayoutMargin(10); myWindow.setAutoChildProperties("header", headerProperties);The above applies a
layoutMarginof 10 to the header of
myWindow, increasing the empty space around the subcomponents of the header (buttons, title label, etc).
Do not use the Properties mechanism for skinning. See Defaults next.
changeAutoChildDefaults()static method of the target Smart GWT class is used to change the defaults for all instances of the class. For example, to change the
Window.changeAutoChildDefaults(String, com.smartgwt.client.widgets.Canvas)API is used passing "header" for the
changeAutoChildDefaults() must be called before any
components are created, and will generally be the first thing in your module's
Class.changeDefaults() inside of a load_skin.js file - see Skinning
ListGridoffers the ability to use simple CSS-based headers or more complex
listGridInstance.setAutoChildConstructor("headerButton", "StretchImg"). To change the constructor of AutoChildren, the
FormItem.setAutoChildConstructor(String, String)API is used.
In order for any class to be referenced within a constructor you must
register the class for reflection, and use the fully qualified name of the target
Reflection for details.
For some drastic customizations of an AutoChild where the constructor is changed, the
signature of the
get[AutoChild]() method may have too specific a return type and
as appropriate would need to be used instead to retrieve the AutoChild instance.
NOTE: When setting Properties or Defaults in Smart GWT, attributes and event handlers can be set, but override points are not supported.
The AutoChild system can be used to create both
and indirect children (children of children). For example, the
minimizeButton of the Window is
also an autoChild, even
though it is actually located within the window header.
Skinning AutoChildren by changing the AutoChild defaults is typically done for two purposes:
In many cases a component will provide shortcuts to skinning or customizing its
AutoChildren, such as
Window.headerStyle, which becomes header.styleName. When
these shortcuts exist, they must be used instead of the more general AutoChild skinning
Before skinning an AutoChild consider the
For a component "Window" with an AutoChild named "header", if you create a Window
myWindow, the header AutoChild is available
Unless documented otherwise, an AutoChild should be considered an internal part of a component. Always configure AutoChildren by APIs on the parent component when they exist. It makes sense to access an AutoChild for troubleshooting purposes or for workarounds, but in general, an AutoChild's type, behavior, and internal structure are subject to change without notice in future Smart GWT versions.
Accessing an AutoChild may give you a way to make a dynamic change to a component that is not otherwise supported by the parent component (for example, changing a text label where there is no setter on the parent). Before using this approach, consider whether simply recreating the parent component from scratch is a viable option. This approach is more than fast enough for most smaller components, and will not create a reliance on unsupported APIs.