com.smartgwt.client.docs

Interface AutoChildUsage

public interface AutoChildUsage

Using AutoChildren

An AutoChild is an automatically generated subcomponent that a parent component creates to handle part of its presentation or functionality. An example is the Window component and its subcomponent the header.

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' Javadocs for "AutoChild" as there is a getter for each AutoChild that is supported. In the case of a MultiAutoChild, the getter is non-functional (always returns null) and exists only to make you aware that the MultiAutoChild exists.

The four different ways to configure AutoChildren in Smart GWT are:

Visibility

Controls whether the AutoChild should be created and shown at all. The Canvas.setAutoChildVisibility(String, boolean) or FormItem.setAutoChildVisibility(String, boolean) API as appropriate is used to change this property for the named AutoChild.

Properties

Properties to apply to the AutoChild created by a particular instance of the parent component. In the case of a MultiAutoChild, the properties are applied to each instance created by the parent.

To change the properties of an AutoChild of a widget, the Canvas.setAutoChildProperties(String, Canvas) or Canvas.setAutoChildProperties(String, FormItem) API is used. To change the properties of an AutoChild of a form item, the FormItem.setAutoChildProperties(String, Canvas) or FormItem.setAutoChildProperties(String, FormItem) 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 layoutMargin of 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.

Defaults

Defaults that will be applied to the AutoChild created by any instance of the parent class. Changing the defaults is used for skinning. The 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.header defaults, the Window.changeAutoChildDefaults(String, Canvas) API is used passing "header" for the autoChildName.

changeAutoChildDefaults() must be called before any components are created, and will generally be the first thing in your module's onModuleLoad() function. Alternatively, you can use the JavaScript equivalent Class.changeDefaults() inside of a load_skin.js file - see Skinning AutoChildren below.

Constructor

SmartClient Class of the component to be created. An advanced option, the AutoChild constructor should generally only be changed when there is documentation encouraging you to do so. For example, ListGrid offers the ability to use simple CSS-based headers or more complex StretchImg headers via listGridInstance.setAutoChildConstructor("headerButton", "StretchImg"). To change the constructor of AutoChildren, the Canvas.setAutoChildConstructor(String, String) or FormItem.setAutoChildConstructor(String, String) API is used.

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 the Canvas.getCanvasAutoChild(String), Canvas.getFormItemAutoChild(String), FormItem.getCanvasAutoChild(String), or FormItem.getFormItemAutoChild(String) API 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 direct children 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

Skinning AutoChildren by changing the AutoChild defaults is typically done for two purposes:

• Changing the default appearance or behavior of a component, for example, making all Window headers shorter
• Creating a customized variation of an existing component while retaining the base component unchanged. For example, creating a subclass of Window called "PaletteWindow" with a very compact appearance, while leaving the base Window class unchanged so that warning dialogs and other core uses of Windows do not look like PaletteWindows.

The best code examples for skinning are in the load_skin.js file for the "SmartClient" skin, in isomorphic/skins/SmartClient/load_skin.js.

Passthroughs (eg window.headerStyle)

In many cases a component will provide shortcuts to skinning or customizing its AutoChildren, such as headerStyle, which becomes header.styleName. When these shortcuts exist, they must be used instead of the more general AutoChild skinning system.

Safe Skinning

Before skinning an AutoChild consider the safe skinning guidelines.

Accessing AutoChildren Dynamically

For a component "Window" with an AutoChild named "header", if you create a Window called myWindow, the header AutoChild is available via myWindow.getHeader().

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.