The WidgetType interface also features the creation of an editor component for a widget at runtime. Again, if you opt to implement the interface yourself, you have to provide this functionality from scratch. If you choose your type to extend ComponentBasedWidgetType, you simply have to add an editor component, just as you did for the widget component. Consequently, the MXML definition for the SimpleSearchWidgetType for simple search widgets that are configurable at runtime looks as follows:

<editor:ComponentBasedWidgetType
        name="..."
        description="..."
        iconCls="...">
  <editor:WidgetComponent>
    <editor:SimpleSearchWidget/>
  </editor:WidgetComponent>
  <editor:EditorComponent>
    <editor:SimpleSearchWidgetEditor/>
  </editor:EditorComponent>
</editor:ComponentBasedWidgetType>

Now widgets of this type have their own editor component when a widget on the dashboard is in edit mode.

However, without further wiring, the changes a user makes in edit mode do not carry over to the widget component. For the simple search widget it is expected that the user can choose a search text and content type in edit mode and that the widget shows a corresponding search result in widget mode. To make this happen, SimpleSearchWidgetEditor has to implement the StateHolder interface. The method getStateValueExpression() has to be implemented in a way that the value expression refers to a simple JavaScript object containing the configuration properties to be applied to the widget component. Thus, for the simple search widget, these properties are searchText and contentType.

See section Section 7.7, “Storing Preferences” for details of how the state values are persisted and for the limits on the allowed objects.

You could just implement the StateHolder interface yourself. For convenience, CoreMedia recommends, that you let your editor component extend StatefulContainer. This component inherently implements StateHolder. It can be configured with a list of property names along with default values and automatically takes care of building a state model bean from them. This state model bean is the basis for the evaluation of the value expression that is returned via getStateValueExpression(). Additionally, the bean can be consulted via getModel() from subclasses of StatefulContainer. This can be utilized for binding the model state to the user interface state. The following listing exemplifies this for the case of SimpleSearchWidgetEditor:

<?xml version="1.0" encoding="UTF-8"?>
<ui:StatefulContainer
        xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:exml="http://www.jangaroo.net/exml/0.8"
        xmlns="exml:ext.config"
        xmlns:ui="exml:com.coremedia.ui.config"
        xmlns:editor="exml:com.coremedia.cms.editor.sdk.config"
        properties="searchText,contentType,preferredSite">
  ...
  <ui:items>
    <editor:ContentTypeSelector fieldLabel="..."
                                entries="{ContentTypeSelectorBase.getAvailableContentTypeEntries()}"
                                anchor="100%"
                                itemId="...">
      <editor:contentTypeValueExpression>
        <ui:ValueExpression expression="contentType"
                            context="{getModel()}"/>
      </editor:contentTypeValueExpression>
    </editor:ContentTypeSelector>
    <TextField fieldLabel="..."
               itemId="..."
               anchor="100%">
      <plugins>
        <ui:BindPropertyPlugin bidirectional="true">
          <ui:bindTo>
            <ui:ValueExpression expression="searchText"
                                context="{getModel()}"/>
          </ui:bindTo>
        </ui:BindPropertyPlugin>
        <ui:BlockEnterPlugin/>
      </plugins>
    </TextField>
  </ui:items>
  <ui:plugins>
    <ui:VerticalSpacingPlugin/>
  </ui:plugins>
  <ui:propertyDefaults>
    <fx:Object contentType="{ContentTypeNames.DOCUMENT}"/>
  </ui:propertyDefaults>
</ui:StatefulContainer>

This editor component for the simple search widget extends StatefulContainer and is configured to build a state model for the two properties searchText and contentType. For the content type property, a default is set. The editor component offers the user a combo box for selecting a content type and a text field for entering a search text. The user's input is tied to the state model via value expressions that use getModel() (inherited from StatefulContainer) as their context. This results in keeping the state model updated. Implementing the StateHolder interface yourself is not necessary. It is automatically taken care of by StatefulContainer on the basis of the always up-to-date state model.

All in all, this results in the simple search widget editor being stateful. When the user switches between widget mode and edit mode for this widget, the editor will keep its state (search text and content type). The state is only lost if the user selects a different widget type in edit mode.

In some cases, it might be useful to not only have the editor of a widget being stateful, but also the widget itself. This can be realized in the same way shown here for the editor: by implementing the StateHolder interface.