| Sun ONE Application Framework IDE Guide |    
|
| Sun ONE Application Framework IDE Guide |
|
| C H A P T E R 3 |
|
Sun ONE Application Framework Component Nodes |
This chapter provides an overview of the various nodes that visually represent the major Sun
ONE Application Framework components that you create in your Sun ONE Application Framework application.
Details about these nodes and Sun ONE Application Framework specific contextual menu actions are presented below.
Each application specific page, pagelet, model, and command component is a subtype of the corresponding Sun ONE Application Framework component which was selected during the application component creation phase. The IDE introspects the base component and dynamically presents component properties which are declared by the library component from which the application component derives. This section focuses on those contextual menu commands and properties which are common to all components of a given type.
Sun ONE Application Framework page components are the primary visual objects in a Sun ONE Application Framework application. At runtime each Sun ONE Application Framework page component can be invoked by a URL and returns a document.
A Sun ONE Application Framework page component consists of a Java class and zero or more associated JSPs. The IDE assists in the construction and configuration of Sun ONE Application Framework pages by exposing the structure of the page as a collection of subnodes. These subnodes are described below.
As you add, subtract, and declaratively configure the component's subnodes, the IDE automatically updates the component's Java source file so that it remains in sync with the component's configuration. The automatically generated Java source code is protected from user modification by being guarded in protected blocks. The IDE does not allow you to edit these protected blocks because they are subject to regeneration whenever the component's configuration changes.
Each application page component is a subtype of the Sun ONE Application Framework page component which you selected during the page creation phase. The IDE introspects the base page component and dynamically presents those component properties which are declared by the library component from which the application component derives.
The following figure shows the Page Component node and its four subnodes.
This opens the page component's Java source file and jumps to the class in the Source Editor.
This opens the page component's default JSP file and jumps to the page in the Source Editor. Each page component might be associated with zero or more JSPs. One of the associated JSP's is designated as the default JSP.
This displays a dialog which describes a list of one or more error messages. The messages describe the configuration inconsistencies so you can take corrective action before proceeding with further configuration or test running of the component.
This command only appears in the node's contextual menu when the component's internal state is in error due to some configuration inconsistency. Whenever the component's internal state is in error, the component node is badged with the standard error or warning badge. The warning or error badge disappears when you have corrected the errors.
This launches a submenu which lists the event handler methods suitable for implementation in this component. The names of already implemented event handlers appear in bold. Those which have not yet been implemented are not in bold.
When you select a bold event handler from the list, the IDE opens the component's Java source and positions your cursor at the start of the event handler. When you select a non-bold event handler, the IDE adds the corresponding event handler's method stub to the component's Java source file and position your curser above it.
The list of available event handler methods is component specific and declared by the component from which the current component is derived. Some components do not declare event handlers. This menu command is inactive if the component does not declare any event handlers.
This launches a submenu which lists useful component methods available for this component to implement. The names of already implemented component methods appear in bold. Those which have not yet been implemented are not in bold.
When you select a bold component method from the list, the IDE opens the component's Java source and positions your cursor at the start of the method. When you select a non-bold component method, the IDE adds the corresponding method stub to the component's Java source file and positions your curser above it.
The list of available component methods is component specific and is declared by the component from which the current component is derived. Some components do not declare component methods. Typically, component methods are a subset of available base class methods which are specifically intended for override by subclasses and deemed important enough by the library component's author to merit exposure in this convenient manner. This menu command is inactive if the component does not declare any event handlers.
This test runs the page. This command launches a browser and invokes the proper URL to request the current page from the IDE's currently configured servlet container. This command does not redeploy the application. Changes made since the last deploy are not reflected in the test run.
This test runs the page. This command automatically compiles the current application, deploys the current application to the IDE's currently configured servlet container, and launches a browser and invokes the proper URL to request the current page.
This sets the name of the component class and renames the component's Java source file.
This deletes the page component. This command deletes the component's Java source file. It also prompts and asks if you also want to delete any JSP files formerly associated with this page.
This provides the conventional cut, copy, and paste behavior.
Do not attempt to copy a page from one Sun ONE Application Framework application into another Sun ONE Application Framework application if the source page contains references to other objects within the source application. The references are not preserved across Sun ONE Application Framework application boundaries.
This specifies this component's fully qualified class name. This property is non-editable.
This specifies this component's fully qualified ComponentInfo class. This property is non-editable.
This sets the name of the component class.
A Page node has four immediate subnodes as follows:
Each of these nodes might have subnodes of its own.
The Java source node provides node level access to this component's Java source file. The Sun ONE Application Framework component node parents the Java source node in order to emphasize that the application component is logically comprised of more than just the Java node. The Java source node is identical to the conventional Sun ONE Studio 5 update 1 Java source node with the following exceptions:
Use the component's cut, delete, and rename commands instead.
The Java Source node contextual menu commands and properties are described fully in the Sun ONE Studio 5 update 1 documentation.
The JSP Pages node lists all of the JSPs that are using the page component--the page component and the JSP are associated. A given page might be associated with zero or more JSPs. Therefore, this node might contain zero or more JSP subnodes. For any given runtime client request a single associated JSP is used to render the page's content. However, Sun ONE Application Framework pages might be coded to conditionally and dynamically utilize any one of its associated JSPs for a give request. This Sun ONE Application Framework feature is known as parallel content. For more details on parallel content, consult the Sun ONE Application Framework Developer's Guide.
Once a JSP is associated with a given Sun ONE Application Framework page, the IDE keeps the page component and its associated JSP in sync. As child visual components are added to the page component, the IDE automatically adds a JSP tag to any and all associated JSPs. Similarly, as child visual components are renamed and deleted, the tags are automatically deleted or renamed in order to maintain design time synchronization. For example, if you add a TextField child visual component named foo to a page component, a jato:textField tag is inserted into all the associated JSPs listed in the JSP Pages node.
This synchronization is one way. Modifications to the page component are automatically reflected in the JSP, but not vice versa. The page component is primary, and the JSP secondary. The JSP uses the page component in a standard uses relationship.
A given JSP might only be formally associated with one Sun ONE Application Framework page. However, since Sun ONE Application Framework pages might contain child visual component of type pagelet, one can easily construct arbitrary compositional hierarchies of page and pagelet, and achieve maximal reuse of application level visual components.
An associated JSP has a jato:useViewBean tag specifying the class name of the page component as shown below:
<jato:useViewBean className="jatotutorial.main.CustomerPage"> |
This associates an additional JSP with the page component. Select a JSP to associate from the list of available JSPs under the current application document root. The OK button in the Choose a JSP Dialog is only enabled when you have selected a JSP which is not associated with any other page at this time. This command modifies the associated JSP's content so that it is configured with the appropriate Sun ONE Application Framework tag library descriptor (tld) directive and a Sun ONE Application Framework JSP tag which declares the use relationship between the associated JSP and this page.
The following figure shows the Choose a JSP Editor.
This creates a new JSP page and associates it with the this page. The newly generated JSP is automatically populated with JSP tags that correspond to all of this page and this page's visual component children. When the new JSP page is created, it is added to this page's list of associated JSP pages, and a new JSP subnode appears under the JSP Pages Node.
This displays a dialog with a list of the current node's subnodes. The dialog has buttons (Move Up and Move Down) that allow you to manipulate the display order of the subnodes.
This specifies the URI for the associated JSP which is currently designated as the Default JSP for this page. The Default JSP is the JSP used to render the current page when this page is test run within the Sun ONE Studio 5 update 1, unless otherwise overridden by page specific code. This property is non-editable.
The value of the current setting for the Default JSP property is reflected in the page component's generated Java source code, as follows:
setDefaultDisplayURL("/jatotutorial/main/CustomerPage.jsp"); |
There can be zero or more JSP Page Nodes under the JSP Pages Node.
The JSP Node provides node level access to a page component's formerly associated JSP file. The JSP node is identical to the conventional Sun ONE Studio 5 update 1 JSP node.
Though the JSP file is physically located under the application's document root directory, and the page component is physically located under the application's WEB-INF/classes directory, the IDE creates a copy of the JSP node so that Sun ONE Application Framework page component developers can have easy access to the associated JSP from within the node hierarchy of the page component.
Note that this is a copy of the node only. There is only one physical JSP file, even though its JSP node appears in two places. This visually confirms that a given JSP is associated with a given page component, and that the IDE automatically synchronizes the content of the JSP as modifications are made to the page component that the JSP uses.
You can see that the JSP node exists in two node hierarchies simultaneously, the document node hierarchy, and the page node hierarchy.
The following figure shows the JSP node.
The JSPs under the Documents node represent the actual JSP files, while the JSPs under the JSP Pages node are simply links to the actual file. This means that if you delete a JSP under the JSP Pages node, you are just removing the visual association it has with the page component in the Sun ONE Studio 5 update 1. However, if you delete a JSP under the Documents node, you are deleting the physical file from disk.
The JSP node contextual menu commands are identical to the conventional Sun ONE Studio 5 update 1 JSP node contextual menu commands with the exception of the commands detailed here. The remaining JSP node contextual menu commands are described fully in the Sun ONE Studio 5 update 1 documentation.
This presents a synchronization editor that allows you to selectively add and remove JSP tags that correspond to the page's visual component hierarchy. This command is merely a convenience utility. You can, of course, manually edit the JSP to add or remove JSP tags. However, the Synchronize to View editor offers a more convenient way of introducing or removing tags in a batch mode.
This editor presents the page component's complete visual hierarchy in a simplified node tree. All of the children from the page component's Visual Components node display as subnodes. In more complex visual component hierarchies, there might be pagelet children, a TiledView for example, that have child visual components as well. The complete view hierarchy, no matter how complex and deep, displays in this editor.
All visual components from the page that are currently referenced by tags in the JSP appear selected (checked). All visual components from the page that are currently unreferenced by tags in the JSP appear as unselected (unchecked). By unchecking and/or checking the various nodes, you can perform a batch modification of the JSP.
This figure shows the synchronization editor.
You can remove undesired tags by unselecting (unchecking) the corresponding node. If a child is also a pagelet (like a TiledView), unselecting it also unselects all of its children, and they are all deleted.
You can add a tag by selecting (checking) the corresponding node. Selecting a pagelet child initially selects all of its children. You may selectively uncheck any of the nested children if you want to do so.
The Delete Tag Body Content checkbox at the bottom of the Synchronization dialog allows you to control the tag deletion policy as it pertains to tags which have existing body content (for example, HREF or pagelet tags). You might choose to have the tool also delete the body content, or leave it intact even while the tag itself is deleted. The Delete tag body content checkbox is unselected by default to prevent existing body content from being deleted without your specific consent.
This sets the current JSP as the Default JSP for the page component.
This deletes the current JSP node from the JSP Pages node and breaks the formal association between the JSP and the page component. However, this command does not physically delete the JSP file from disk. By invoking this command you are just removing the visual association between the JSP file and the current page component. If you want to delete the physical JSP file, delete the actual JSP node under the Document root.
The JSP node properties are identical to the conventional Sun ONE Studio 5 update 1 JSP node properties, with the exception of the properties detailed here. The remaining JSP node properties are described fully in the Sun ONE Studio 5 update 1 documentation.
This specifies the JSP file location under the application document root. This is purely a convenience property which allows developers to see at a glance the physical location of the JSP file. This property is non-editable.
Non-visual components are those non-visual components used by the page component. For example, a page component might use or refer to zero or more Models, zero or more Command components. These references can be configured declaratively as non-visual component nodes. Component libraries might introduce arbitrary non-visual components for use as well. The IDE generates the corresponding Java code to reflect the declarative configuration of these non-visual resources.
The following figure shows the non-visual components node and its children.
Because these non-visual components are essentially just JavaBeans, the types of components that can appear here is limitless, and therefore, the property sheets for each type will vary. Typically, you will define non-visual components, because your page's visual components contain properties with values that must be set to refer to non-visual components. The classic example of this internal uses relationship is the visual component's ModelReference property which is satisfied by referring to a non-visual ModelReference component. Some of the visual component property editors implicitly create non-visual components when you configure those properties. You might also explicitly add non-visual components to the page.
A given non-visual component might be used by zero or more visual components within the current page.
This explicitly adds an arbitrary new non-visual component. Select from the list of available non-visual components in the Sun ONE Application Framework component libraries that are registered in your Sun ONE Application Framework application.
The following figure shows the Non-Visual Component Browser.
This displays a dialog with a list of the current node's subnodes. The dialog has buttons (Move Up and Move Down) that allow you to manipulate the subnodes display order.
The non-visual components subnodes consists of zero or more non-visual component nodes.
A non-visual component node provides declarative configuration for a non-visual component which is instantiated in the scope of the current page. The IDE automatically generates the code to instantiate the non-visual component within the page's Java source file.
This provides conventional cut, copy and paste behavior.
This deletes the non-visual component node. Upon deletion of a non-visual component, any visual components which have property values still holding a reference to the deleted non-visual component are badged with a warning. The error information available on the page node describes the stale property references in detail so that you can clean them up.
Each non-visual component has three property tabs:
The Properties and Code Generation property tabs contain the same properties for all non-visual components and are described below.
The Component Properties tab, however, contains properties which are specific to a given non-visual component type. Since the non-visual components are arbitrary JavaBeans, these bean specific properties are dynamically discovered by the IDE and presented for editing in the Component Properties tab. These non-visual component specific properties are not documented here since they are component specific.
This specifies the fully qualified class name for the non-visual component. This property is non-editable.
This specifies the non-visual component's logical name. This is the name that appears wherever the non-visual component is referenced by visual component properties within the scope of this page component. The IDE also factors the value of the name property into the code it generates to manage the construction and access to the non-visual component within the page's Java source file. The exact code which is generated varies depending on the values of the three related code generation properties:
This specifies the access privilege which the IDE's code generation engine applies when it generates the code which provides access to the non-visual component instance within the page's Java source.
This specifies a scope setting that allows you to influence the IDE's code generation engine when it generates the code which provides access to the non-visual component instance within the page's Java source.
This specifies an HTTP session attribute name. If the scope property is set to HTTP Session, the code generation engine uses the specified session attribute name when it generates the code that provides access to the non-visual component instance within the page's Java source.
The Visual Components node contains zero or more child visual component nodes. This is the heart of the visual component story. The page node forms the root of the hierarchy. It might contain zero or more visual component subnodes. Any visual components subnode which is a pagelet component may itself have child visual components. This allows for an arbitrarily deep visual component hierarchy.
The following figure shows the Visual Components node and its various types of visual children.
This adds a new visual component node. This command presents a component chooser editor. The effect of choosing a component from the component chooser is functionally equivalent to adding a visual component by clicking on the Component palette. They are two equally valid ways to add a visual component.
The Component Browser editor displays with at least two nodes: Current Application Components and the Sun ONE Application Framework Component Library.
If you added a third party Sun ONE Application Framework component library JAR files to your WEB-INF/lib directory, you would see additional nodes representing those component libraries as well. For more information about creating your own reusable, distributable Sun ONE Application Framework component libraries, consult the Sun ONE Application Framework Component Developer's Guide.
The following figure shows the Component Browser.
For every visual component node which is added to the page in this manner, the IDE generates a component constructor invocation, a component accessor method, and a class constant for the component instance name. Additionally, a corresponding component specific JSP tag is inserted in all JSPs using the page component.
All of this automation facilitates a more consistent and less error prone application. If you require more flexibility with the creation of your visual components, manual creation is an option. See the Sun ONE Application Framework Developer's Guide.
Paste a visual component. When pasting a visual component which was copied or pasted from a different page, any non-visual components referred to by the original visual component node is not automatically carried forward into the new page.
This displays a dialog with a list of the current node's subnodes. The dialog has buttons (Move Up and Move Down) that allow you to manipulate the subnodes display order.
The visual component subnode consists of zero or more visual component nodes.
A visual component node might be a simple visual component node (for example, text fields, choice fields, command fields, and so on) or a pagelets node (for example, TiledViews, ContainerViews, and TreeViews). A pagelet node is expandable into its own visual component subnodes, thereby allowing for an arbitrary visual component hierarchy.
This launches a submenu which lists the child specific event handler methods suitable for implementation within the parent component's source code file. The names of already implemented event handlers appear in bold. Those which have not yet been implemented are not in bold. When you select a bold event handler from the list, the IDE opens the parent component's Java source and positions your cursor at the start of the event handler. When you select a non-bold event handler, the IDE adds the corresponding event handler's method stub to the parent component's Java source file and positions your curser above it. Since the event handlers need to be child component specific, the IDE generates the event handler methods so that the method name is uniquely named, based on the child component's instance name. For example if the event handler appears as beginDisplay in the events menu, and the visual component instance is named foo, then the IDE generates a handler method named beginFooDisplay.
The list of available child component event handler methods is determined by the parent component's ability to dispatch child component specific events. This ability is declared by the component from which the current page component is derived. The visual component node's event contextual menu command is inactive if the page component does not declare any event handlers for the current child component type.
All visual component nodes share a few common properties. Each visual component also has an arbitrary number of visual component specific properties which the IDE dynamically discovers and presents for your configuration within the property sheet.
This specifies this visual component's fully qualified class name. This property is non-editable.
This specifies this visual component's fully qualified ComponentInfo class. This property is non-editable.
Specifies the visual component's instance name. The IDE also factors the value of the name property into the code it generates to manage the construction and access to this visual component within the page's Java source file.
This specifies a block of arbitrary Java code which is inserted by the code generation engine immediately following the invocation of the visual component's constructor. This pre-initialization code is therefore inserted before any of the explicit property setters are invoked. This allows you to insert code into the otherwise non-editable section of the page's Java file.
This specifies a block of arbitrary Java code which is inserted by the code generation engine immediately after all of the automatically generated component specific property setter invocation code. This allows you to insert code into the otherwise non-editable section of the page's Java file.
Pagelet nodes are virtually identical to Page nodes. They both have similar subnodes, contextual menu commands, and properties. There is one notable exception. Pagelets nodes are not executable the way Page nodes are. This is because pagelets are subpages, or page fragments. They are intended to provide visual building blocks for other more complex visual components and ultimately for inclusion, directly or indirectly as children of page components. Page components form the root of an arbitrary visual component hierarchy. The pagelets form the branches of a given visual component hierarchy. A pagelet may contain zero or more other pagelet children. A given pagelet may be a child of any number of other pagelet or page components.
One example of a pagelet is the TiledView component. The TiledView has built-in iteration behavior. It is commonly used to iterate over a result set to display the values of the columns of each of the rows (tiles).
The pagelet contextual menu commands are identical to the Page node's contextual menu commands, except that the pagelet node does not have an execution command. Pagelets cannot be test run. They are not addressable via URL the way pages are.
See Page Component Node Contextual Menu Commands.
See Page Component Node Contextual Menu Commands.
See Page Component Node Contextual Menu Commands.
It is perfectly acceptable for a Pagelet node not to have any associated JSP nodes. This may sound counterintuitive until you realize that the Sun ONE Application Framework Pagelet is first and foremost a visual component hierarchy. The rendering of the visual component hierarchy is controlled by corresponding JSP tags, but the JSP tags do not need to be isolated to a pagelet specific JSP fragment.
In the classic pagelet use case, the tags for rendering the pagelet's own visual component hierarchy might be isolated in reusable JSP fragment(s) and formally associated with the Pagelet component as a JSP subnode(s). If this is the case, whenever the pagelet is added as a child to another container, the IDE adds a single JSP include tag to the parent visual component's JSP file(s). The include tag includes the pagelet's JSP fragment in conventional JSP include fashion. This is the approach to take when you want the pagelet's rendering to be identical in each context in which it appears as a child.
However, there are cases where you may want a pagelet's visual layout to vary as that pagelet is used within different parent components. In that case, you might intentionally refrain from explicitly associating any JSPs with the pagelet. In this case, whenever the pagelet is added as a child to another visual component, the IDE adds tags for the pagelet and its children to the parent visual component's JSP file(s), thereby creating a deep tag hierarchy in the parent's JSP file(s). This allows the parent JSP to be edited as a single document, which some JSP authors prefer. The Sun ONE Application Framework offers you the choice and allows you to decide on a pagelet specific basis.
Models are classes that serve as a storage mechanism and/or a proxy to data for the application's views (pages and pagelets). There are several types of models that ship with Sun ONE Application Framework: JDBC SQL Query, JDBC Stored Procedure, Web Service, Resource Bundle, Bean Adapter, Custom, HTTP Session, Tree, Object Adapter, and more.
The following figure shows examples of model component nodes.
This opens the component's Java source file and jumps to the class in the Source Editor.
This launches a submenu which lists the event handler methods suitable for implementation in this component. The names of already implemented event handlers appear in bold. Those which have not yet been implemented are not in bold. When you select a bold event handler from the list, the IDE opens the component's Java source and positions your cursor at the start of the event handler. When you select a non-bold event handler, the IDE adds the corresponding event handler's method stub to the component's Java source file and positions your curser above it. The list of available event handler methods is component specific and declared by the component from which the current component is derived. Some components do not declare event handlers. This menu command is inactive if the component does not declare any event handlers.
This launches a submenu which lists the special design actions available for this component. A design action is an arbitrary function provided by the component author which may operation on or mutate the configuration of the component. A design action can be silent, or it might display a customizer for the component.
This launches a submenu which lists useful component methods available for this component to implement. The names of already implemented component methods appear in bold. Those which have not yet been implemented are not in bold. When you select a bold component method from the list, the IDE opens the component's Java source and positions your cursor at the start of the method. When you select a non-bold component method the IDE adds the corresponding method stub to the component's Java source file and positions your curser above it.
The list of available component methods is component specific and declared by the component from which the current component is derived. Some components will not declare component methods. Typically, component methods are a subset of available base class methods which are specifically intended for override by subclasses and deemed important enough by the library component's author to merit exposure in this convenient manner. This menu command is inactive if the component does not declare any event handlers.
Sets the name of the component class and renames the component's Java source file.
Deletes the component. This command deletes the component's Java source file.
Provides the conventional cut, copy and paste behavior.
Specifies this component's fully qualified class name. This property is non-editable.
Specifies this component's fully qualified ComponentInfo class. This property is non-editable.
Sets the name of the component class.
Different types of models can have slightly different subnodes. All models have a Java Source subnode just like the page and pagelet nodes. Model components may have zero or more model field group nodes and models also may support a model operation group node.
The optional model field group node logically represents a set of zero or more named model fields. Visually, the model field group node is parent to zero or more model field nodes. The type of the model field is arbitrary and decided by the component author. The label for the model field group node usually changes depending upon the type of model field it exposes.
All the model fields across all the model field groups must have unique names. In other words, there is one set of uniquely named model fields for the entire model but the component author may allow the model fields to be partitioned into different groups so that different types of fields are supported.
It is possible for a model to have zero model field groups, in which case views will bind to the models with anonymous bindings entered manually. It is also possible for a model to only expose internally generated automatic fields through the binding chooser even though there are no model field nodes or model field group nodes for that model. All this depends upon the decisions made by the component author and the kind of data which the model is managing. A model component that exposes hundreds or thousands of bindings could be designed. In this case, it is not desirable to represent all the fields as nodes, and the component author would instead provide a specialized chooser for the view binding.
The optional model operation group node logically represents a set of zero or more named model operations. Visually, the model operation group node is parent to zero or more model operation nodes. The label for the model operation group node might change depending upon the type of model operation it exposes. However, the label is usually Operations.
The Java Source Node provides node level access to this component's Java source file. The Sun ONE Application Framework component node parents the Java source node to emphasize that the application component is logically comprised of more than just the Java node. The java source node is identical to the conventional Sun ONE Studio 5 update 1 Java source node with the following exceptions:
The Java Source node contextual menu commands and properties are described fully in the Sun ONE Studio 5 update 1 documentation.
This is a node that parents a group of zero or more model field nodes.
Add a new model field to the group. A new subnode is added for the model field. The name of the field defaults to a unique name derivative of a basename defined by the model component author. The developer might immediately change that name as desired. The addition of the model field updates the generated code section of the model's Java file.
This displays a dialog with a list of the current node's subnodes. The dialog has buttons (Move Up and Move Down) that allow you to manipulate the subnodes display order.
There are zero or more model field subnodes for each model field group node
This provides direct access to the model field properties and editing actions.
This provides conventional cut, copy, and paste behavior. Upon a move of a model field to another model, any visual components bound to that field will have their binding eliminated.
This renames the model field node. Upon a rename of a model field any visual components bound to that field will have their binding updated.
This deletes the model field node. Upon a delete of a model field, any visual components bound to that field will have their binding eliminated.
All model field nodes share a few common properties which will be described here. Each model field also has an arbitrary number of specific properties which the IDE dynamically discovers and presents for your configuration within the property sheet.
This specifies the model field's instance name. The IDE also factors the value of the name property into the code it generates to manage the construction and access to this model field within the page's Java source file.
This is a node that parents a group of zero or more model operation nodes.
This adds a new model operation to the group. A new subnode is added for the model operation. The name of the field defaults to a unique name derivative of a basename defined by the model component author. The developer might immediately change that name as desired. The addition of the model operation updates the generated code section of the model's Java file.
This pastes a model operation.
This displays a dialog with a list of the current node's subnodes. The dialog has buttons (Move Up and Move Down) that allow you to manipulate the subnodes display order.
There are zero or more model operation subnodes for the model operation group.
Provides direct access to the model operation properties and editing actions.
This provides conventional cut, copy and paste behavior. Upon a move of a model operation to another model, any non-visual components indicating this operation name in a property are not updated. It is up to the developer to manually reset operation name value on non-visual components.
This renames the model operation node. Upon a rename of a model operation, any non-visual components indicating this operation name in a property are not updated. It is up to the developer to manually reset operation name value on non-visual components.
This deletes the model field node. Upon a delete of a model field, any non-visual components indicating this operation name in a property are not updated. It is up to the developer to manually reset operation name value on non-visual components.
All model operation nodes share a few common properties which will be described here. Each model operation also has an arbitrary number of specific properties which the IDE dynamically discovers and presents for your configuration within the property sheet.
This specifies this model operation's fully qualified class name. This property is non-editable.
This specifies the model operations's instance name. The IDE also factors the value of the name property into the code it generates to manage the construction and access to this model operation within the page's Java source file.
Commands are the controller components of your application. A command can be created to handle specific types of actions when a command field (button or HREF) is clicked, for example.
A single command component can be reused by many different command fields throughout your application. Behavior can be further customized, based upon parameters that are passed into the command component by the many command fields using the command component.
For more details on command component authoring, consult the Sun ONE Application Framework Developer's Guide and the Sun ONE Application Framework Component Developer's Guide.
The following figure shows examples of command component nodes.
This opens the component's Java source file and jumps to the class in the Source Editor.
This launches a submenu which lists the event handler methods suitable for implementation in this component. The names of already implemented event handlers appear in bold. Those not yet implemented are not in bold.
When you select a bold event handler from the list, the IDE opens the component's Java source and positions your cursor at the start of the event handler. When you select a non-bold event handler, the IDE adds the corresponding event handler's method stub to the component's Java source file and position your curser above it.
The list of available event handler methods is component specific and declared by the component from which the current component is derived. Some components will not declare event handlers. This menu command is inactive if the component does not declare any event handlers.
This launches a submenu which lists useful component methods available for this component to implement. The names of already implemented component methods appear in bold. Those which have not yet been implemented are not in bold.
When you select a bold component method from the list, the IDE opens the component's Java source and positions your cursor at the start of the method. When you select a non-bold component method the IDE adds the corresponding method stub to the component's Java source file and positions your curser above it.
The list of available component methods is component specific and declared by the component from which the current component is derived. Some components will not declare component methods.
Typically, component methods are a subset of available base class methods which are specifically intended for override by subclasses and deemed important enough by the library component's author to merit exposure in this convenient manner. This menu command is inactive if the component does not declare any event handlers.
This sets the name of the component class and renames the component's Java source file.
This deletes the component. This command deletes the component's Java source file.
This provides the conventional cut, copy, and paste behavior.
This specifies this component's fully qualified class name. This property is non-editable.
This specifies this component's fully qualified ComponentInfo class. This property is non-editable.
This sets the name of the component class.
Command nodes only have one subnode: the Java Source node.
The Java source node provides node level access to this component's Java source file. The Sun ONE Application Framework component node parents the Java source node to emphasize that the application component is logically comprised of more than just the Java node. The java source node is identical to the conventional Sun ONE Studio 5 update 1 Java source node with the following exceptions.
The Java Source node contextual menu commands and properties are described fully in the Sun ONE Studio 5 update 1 documentation.
| Sun ONE Application Framework IDE Guide | 817-4104-10 |
|
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.
[action] 
