With the Visual Composition Editor, you lay out beans
graphically and specify their interaction using a high-level connection
model. When you save your composition, VisualAge generates Java code
that maps this graphical representation to the JavaBeans component model and
to the APIs for the beans themselves. The resulting generated code is
best understood if you are familiar with the JavaBeans component model; in
fact, it is quite similar to code that an expert JavaBeans programmer would
have written by hand. If you are interested in understanding more about
the code generated by VisualAge, read the
JavaBeans specification
first; then read the rest of this section and look at the code generated by
VisualAge for different visual compositions.
Some items are generated only once; others are regenerated every time the
product detects a relevant change. Some items are generated only if you
have indicated to VisualAge that you want certain capabilities present in your
bean. Methods that are regenerated whenever the product detects a
relevant change are indicated by
to the right of the method signature.
Note: | The code resides in the VisualAge repository, not as code files in your
working directory. To get a copy of your code or compiled class in a
file, you must export the class.
|
When you compose your bean visually, VisualAge generates
much of the user interface code for you. The connections you make
between beans are often sufficient to define behavior at run time. If
not, you can extend it by adding your own code.
In addition to other items generated for all classes, VisualAge generates
the following code for a composite bean. This code is generated when
you save the bean, select Re-generate Code from the Bean menu of
the Visual Composition Editor, or select
Run:
- A field declaration for each embedded bean, which takes its name from the
name given to the bean when it was dropped in the Visual Composition
Editor. This field is declared as private. To minimize potential
collisions between handwritten and generated code, all generated field names
start with ivj.
- A private get method for each embedded bean, which takes its name from the
name given to the bean when it was dropped in the Visual Composition
Editor. Because Variable and Factory beans represent instances that do
not exist at initialization, VisualAge generates public get and set methods
for them so that they can be set at run time. Serialized instances are
restored in the get method through a call to
Beans.instantiate( ); other instances are created in the
get method in a new expression if they do not already exist.
Note: | Take care when renaming embedded beans or torn-off properties.
Otherwise, VisualAge might generate an accessor method that overrides an
inherited method or overwrites a user-written method.
|
- For each promoted feature, a public get and set method. If the
promoted feature's name is the same as that of the bean in which the
feature resides, VisualAge generates the bean's get and set methods as
public instead of private.
- If at least one hidden-state bean is used, a serialized-object file
(.sos) that takes its name from that of the composite class (for
example, ivjMyComposite.sos). VisualAge also generates a
getSOSByteArrayCache( ) method, which reads a byte stream from
the serialized-object file into an instance variable for deserializing.
- A private method for each method or code connection. For each
property-to-property connection where both end points are writable, two
methods are generated. Parameter connections appear in code as
secondary calls within the original connection.
The name of the connection method depends on the type of connection you
draw. By default, the naming convention is connFtoFx, where
F represents the type of feature being connected and x is an index number to
ensure uniqueness. This translates into the following possible
combinations:
- connEtoM1 (the first event-to-method connection drawn)
- connEtoS1 (the first event-to-code connection drawn)
- connPtoP1setTarget (the first property-to-property connection drawn,
setting the target from the source)
- connPtoP1setSource (the first property-to-property connection drawn,
setting the source from the target)
When you rename a connection, VisualAge deletes the obsolete connection
method and generates a new method whose name is compatible with the
connection's new name.
- For each event set connected to within the composite, listener methods to
fulfill the listener interface's implementation requirements. For
events in the set that are not currently being used, VisualAge generates stubs
only.
- An initConnections( ) method, which contains a call to
every notifier required for event connections in the composite bean.
This method is not generated if there are no connections in the
composite. For example, if your bean contains a connection from the
actionPerformed event of Button1, this method contains the
call:
getButton1().addActionListener(this);
- For applets, an init( ) method.
- For nonapplets, an initialize( ) method.
- A constructor with no arguments, which by default calls the superclass
contructor and the initialize( ) method.
VisualAge also generates the following methods if they do not exist:
- main(java.lang.String [ ]). If you
copy, rename, or move the bean, you must delete this generated method,
regenerate code for the composite, and save the bean.
- For applets, getAppletInfo( ).
- getBuilderData( ), which contains visual layout information
for restoring the free-form surface if the bean is exported and then imported
into another VisualAge Java development environment. This method is
generated only if the appropriate design-time option has been set in the
Workbench.
- handleException(java.lang.Throwable), a stub
method for debugging that gets called in init( ) and the set
methods.
The term feature refers to an element of the
bean interface. Features can be properties, methods, or events.
To add features to the interface, use SmartGuides available from the BeanInfo
page.
The following items are generated for each feature added from the BeanInfo
page.
- For each property, VisualAge generates the following:
- A declaration for a field, defaulting to package-private access
- If the property is readable, a get method
- If the property is writable, a set method
- If the property is indexed, two additional methods for you to access
individual elements
- If at least one property is bound, the propertyChange event and
associated program elements are generated:
- propertyChange, a field of type
java.beans.PropertyChangeSupport, declared as
protected transient
- addPropertyChangeListener(java.beans.PropertyChangeListener),
a public method
- firePropertyChange(java.lang.String,
java.lang.Object, java.lang.Object), a
public method
- removePropertyChangeListener(java.beans.PropertyChangeListener),
a public method
- If at least one property is constrained, the vetoableChange
event and associated program elements are generated:
- vetoableChange, a field of type
java.beans.VetoableChangeSupport, declared as
protected transient
- addVetoableChangeListener(java.beans.VetoableChangeListener),
a public method
- fireVetoableChange(java.lang.String,
java.lang.Object, java.lang.Object), a
public method
- removeVetoableChangeListener(java.beans.VetoableChangeListener),
a public method
- For each event set, VisualAge generates the following items:
- A declaration for a protected listener field
- Public addListener and removeListener methods
- For each new listener interface, VisualAge generates the following
items. VisualAge gives you the opportunity to specify your own names
for these items before they are created.
- An event class in the same package as the class being edited
- A listener interface in the same package
- A multicaster class in the same package
- An event feature in the class being edited
- Public addListener and removeListener methods in the class being edited
In addition, VisualAge creates a BeanInfo class when you add the first
feature. After that, VisualAge updates the BeanInfo class to reflect
each feature changed from the BeanInfo page.
BeanInfo code defines the public interface of your bean in a
standard way. Specifying BeanInfo code enables your bean to be used
with any development tool, including VisualAge, that supports the JavaBeans
specification. With BeanInfo code available, enabled tools can query an
instance of your bean for information about its interface, regardless of
underlying implementation.
VisualAge generates BeanInfo class code as needed to capture the interface
details you specify on the BeanInfo page for your bean. If a BeanInfo
class does not exist for the bean, VisualAge uses the process of
reflection, matching interface features against Java design
templates, to create the class. If a BeanInfo class does exist,
VisualAge generates BeanInfo code only for interface elements defined as bean
features (properties, methods created from the BeanInfo page, and
events). For more information about reflection, see the
JavaBeans specification
.
The following items are generated when you add features to the bean from
the BeanInfo page:
- A classNameBeanInfo class in the same package. This type
of class normally contains several list and descriptor methods, which enabled
tools call to get information about the bean. A list of the most
commonly generated methods follows:
- getBeanClass( ), which returns a instance of
java.lang.Class that corresponds to the bean.
- getBeanClassName( ), which returns a String whose value is
the full name of the bean.
- getEventSetDescriptors( ), which returns an array of
descriptors corresponding to the event sets implemented in the bean.
- getMethodDescriptors( ), which returns an array of
descriptors corresponding to the method features implemented in the
bean.
- getPropertyDescriptors( ), which returns an array of
descriptors corresponding to the properties implemented in the bean.
- findMethod(Class, String, int), used to locate a descriptor
method that is requested by name but not found.
- getAdditionalBeanInfo( ), generated only if you opted to
inherit BeanInfo from the bean's superclass. (This is set from the
Design Time page of the Options notebook.)
- getBeanDescriptor( ), which returns general information
about the bean:
- If you marked the bean as expert, this method calls
setExpert(true).
- If you marked the bean as hidden, this method calls
setHidden(true).
- If you require all instances of the bean to be serialized, this method
calls setValue("hidden-state", Boolean.TRUE).
- For applets, an appletInfoPropertyDescriptor method used to get
information about the appletInfo property.
- For each method feature in the bean being browsed, a public
methodNameMethodDescriptor method in the associated BeanInfo
class. This descriptor method determines how information about the
method is revealed: its true name, its display name, and a description
of the bean. If you created the bean in VisualAge, the descriptor
method reflects selections you made through the New Method Feature
SmartGuide.
- handleException(java.lang.Throwable), a stub
method for use in debugging.
- For each property, a public propertyNamePropertyDescriptor
method in the associated BeanInfo class:
- If you opted to bind the property to an event, this method calls
setBound(true).
- If you marked the property as expert, this method calls
setExpert(true).
- If you marked the property as preferred, this method calls
setValue("preferred", Boolean.TRUE).
- If you marked the property as design-time to keep it from appearing in the
property sheet at run time, this method calls
setValue("ivjDesignTimeProperty", Boolean.FALSE).
- If at least one property is bound, the following methods:
- addPropertyChangeListenerMethodDescriptor( ), a public
method in the associated BeanInfo class
- removePropertyChangeListenerMethodDescriptor( ), a public
method in the associated BeanInfo class
- For each method, a public methodNameMethodDescriptor( )
method in the associated BeanInfo class. If you opted to hide the
method, the descriptor method calls setHidden(true).
Note: | If a BeanInfo class already exists, VisualAge does not generate BeanInfo
descriptors for methods added from the Methods page.
|
- For each event set, public event descriptor methods in the associated
BeanInfo class (for example, actionEventSetDescriptor( ) and
actionactionPerformed_javaawteventActionEventMethodEventSetDescriptor( )
)
- For each new listener, a public event descriptor method in the associated
BeanInfo class (for example, stringModifiedEventSetDescriptor
( ),
stringModifiedSignalModification_CodeGenStringModifiedEventMethodEventDescriptor( ),
and
stringModifiedSignalModification_javalangObjectMethodEventDescriptor( )).
Generated code falls into the following categories:
Items generated only if they do not exist. These include
main(java.lang.String[]),
handleException(java.lang.Throwable), and
getAppletInfo( ). You can write your own versions or
modify generated versions; VisualAge preserves your code.
Items regenerated around handwritten changes. Most code
of interest falls into this category. These methods contain the
reminder comment WARNING: THIS METHOD WILL BE
REGENERATED. and are indicated by
to the right of each method signature. The rest of this section
describes how VisualAge handles this type of generated code.
In general, VisualAge preserves handwritten changes to basic class
declarations, as follows:
- package and import statements associated with the
class.
- Access and keyword modifiers for the class.
- Interfaces implemented completely by hand.
- Uniquely named fields, as long as their names do not start with
ivj. Because VisualAge uses ivj to mark generated
fields, handwritten fields starting with ivj will be deleted the
next time VisualAge generates code for the class. VisualAge does not
preserve updates to access modifiers (private, public, protected) in generated
fields.
- Uniquely named methods, including exceptions. VisualAge preserves
updates to access modifiers (private, public, protected) in generated methods
if the updates render access less restrictive.
- Handwritten comments in generated methods.
You can add lines of code in designated areas of generated methods.
VisualAge indicates these areas in the generated code with comment lines
similar to the following:
//user code begin {1}
//user code end
If a generated method does not include comment lines like these, any code
you add will be overwritten the next time the bean is saved.
How Classes and Beans Are Related
Visual Composition Editor Overview
Working with Beans Visually
Connecting Beans
Defining Bean Interfaces for Visual Composition
Example of Generated Feature Code
Example of Code Generated from Visual Composite
Beans for Visual Composition
