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.
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.
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
Note that you will typically return a value for this behavior only when you haven't supplied an attribute editor (in other words, when you're not returning an editor for the BEHAVIOR_ATTRIBUTE_EDITOR behavior). That's because when you have an attribute editor, that class will have been used to edit the value, and you will probably have called your validator class from its code.
Note: Be aware that there are two mechanisms for validating attribute values. The value you return for the BEHAVIOR_ATTRIBUTE_VALIDATOR behavior defines the validator to use when the user has chosen to edit the attribute's value and it needs validating. In contrast, you can specify a class that should be used by the compiler for validating the value in source code, in the property annotation. You specify that class in the property tags XML file, in the class-name attribute of a custom attribute type. In other words, that's the class WebLogic Workshop uses to know when to display red squiggles for the tag's code. You can define a single class for both kinds of validation, Creating Attribute Editors and Validators.
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; }
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.
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).
The following attributes guide the control's appearance in palettes, such as the Data Palette, and in the Insert menu.
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.
None.