Controlling Appearance and Handling Actions in Design View

WebLogic Workshop provides several ways for you to specify your control's appearance in the IDE. These are exposed in two ways:

This topic describes these two areas.

Providing Editor Support

An "editor support" class is a kind of traffic cop that directs the IDE to specific responses for events in Design View. From the IDE's perspective, control characteristics in Design View are known as behaviors. You write code to give specifics for behaviors by implementing an editor support class — one that implements the EditorSupport interface. An easy way to provide an editor support implementation is to use or extend the DefaultEditorSupport class. You connect your editor support implementation to the IDE by specifying its fully-qualified name in control's the property annotation XML file. This name is the value of the editor-class attribute of the control-tags element.

Implementing the EditorSupport Interface

The EditorSupport interface defines constants for the behaviors supported by the IDE. It also has a single method, getBehavior, that you can implement to tell the IDE the details for each of the behaviors. You implement the getBehavior method in your editor support class, and the IDE calls this method to retrieve your specific instructions for the current behavior.

When calling the getBehavior method, the IDE passes in two arguments. The first of these is an EditorSupport interface constant representing the behavior, such as EditorSupport.BEHAVIOR_EDIT_METHOD or EditorSupport.BEHAVIOR_ATTRIBUTE_VALIDATOR.

The second argument is an instance of an interface that extends the ControlBehaviorContext interface. You use this context interface to discover specifics about the control "piece" (method, control interface, control extension, and so on) that the control's user is currently interacting with. Your getBehavior implementation tests for a combination of these, then returns a response based on the results. The following lists the EditorSupport constants passed in by the IDE, along with the possible contexts you could test for. Note that each context object provides methods for getting information specific to that context. For each behavior, a default return value is used if your code doesn't handle the specific behavior/context pair.

BEHAVIOR_ICONS

BEHAVIOR_MAINICON

BEHAVIOR_EDIT_METHOD

BEHAVIOR_EDIT_CALLBACK

BEHAVIOR_ATTRIBUTE_EDITOR

BEHAVIOR_ATTRIBUTE_VALIDATOR

The following getBehavior implementation example illustrates handling for a few of these behaviors.

public Object getBehavior(String behavior, ControlBehaviorContext context)
{
    Object response = null;
    /*
     * If the user asks to edit a JCX method, return true.
     */
    if (behavior.equals(EditorSupport.BEHAVIOR_EDIT_METHOD))
    {
        response = Boolean.TRUE;
    }
    /*
     * If the user asks to edit a callback, return false. XQuery JCX files do
     * not support callbacks.
     */
    else if (behavior.equals(EditorSupport.BEHAVIOR_EDIT_CALLBACK))
    {
        response = Boolean.FALSE;
    }
    /*
     * If the user clicks an edit ... in the Property Editor, and if the attribute
     * corresponding to the ... is "expression", return an instance of the expression
     * edit dialog box.
     */
    else if (behavior.equals(EditorSupport.BEHAVIOR_ATTRIBUTE_EDITOR))
    {
        if (context instanceof ControlAttribute && ((ControlAttribute)context).getName().equals("expression"))
        {
            // The attribute editor dialog is constructed with the attribute's current value.
            response = new QueryExpressionEditorSimple(((ControlAttribute)context).getValue());
        } 
    }
    return response;
}

Extending the DefaultEditorSupport Class

DefaultEditorSupport is a simple implementation for when your editor support needs are very small. For example, imagine that you don't want to bother with checking for context objects, and just want to, say, set an icon for display in Design View. Your implementation might look something like this:

public class MyEditorSupport extends DefaultEditorSupport
{
    public MyEditorSupport()
    {
        setBehavior(BEHAVIOR_MAINICON, "/myicons/main.gif");
    }
}

However, there's no particular reason to extend DefaultEditorSupport if you're implementing getBehavior yourself.

Using jc-jar Properties to Specify Control Characteristics

The JCS file that's the basis for your control provides a jc-jar with several attributes that you can use to specify how you control appears to the user (or even whether it appears).

Properties for Palette Display

The following attributes guide the control's appearance in palettes, such as the Data Palette, and in the Insert menu.

Properties for Property Editor Display

Note that in a JCS, methods also provide an attribute that determine whether the method should be visible to the control's users. To hide a method, click the method in Design View, locate its ide property in the Property Editor, then select true for the hide attribute.

Other Properties

Related Topics

None.