Method and apparatus for visually creating and testing object oriented components6633888Abstract In order to test component class code with a conventional visual builder, a proxy component is created for each method, including constructors, in the component class code, which proxy component encapsulates the parameters of that method. In particular, parameters associated with a method are represented by properties of the proxy component created for that method. When each proxy component is displayed on the GUI of the visual builder, its properties, and consequently, the parameters of the underlying method, are visually editable and can be bound visually to other component properties using, for example, a mechanism in a conventional visual builder which links objects. Exceptions which occur during operation of the method are treated as events and can be visually passed to other components. Therefore, a program can be visually constructed and parameterized for runtime operation. In order to actually run components to test them a universal transport application under control of the proxy components provides a mechanism for manipulating local or remote objects in a "component-oriented" manner directly from the visual builder. Claims What is claimed is: Description FIELD OF THE INVENTION
public Address getAddress (
String firstName,
String lastName);
Unlike the conventional extraction process of "reflection", which would only determine that the method takes as parameters two string objects, the bean compiler 300 extracts the actual parameter names "firstName" and "lastName". Extracting these parameter names allows these parameters to be converted to properties of the method bean created from the original method "getAddress". Maintaining these parameters as properties allows more flexibility in the construction and customizing of new beans created from the getaddress method bean. As previously mentioned, component creator 200 functions to convert Java class code and other Java beans into proxy beans which can be combined to form a "bean-based" application by a conventional visual builder. In particular, Java class or Java bean interface code 204 is provided to bean compiler 208. Code 204 is either local or, in the case of a distributed object system, is generally exported by the remote server. As previously mentioned, bean compiler 208 generates a constructor bean for each constructor in the code and a method bean for each method. These proxy beans 210 lo are provided to a visual builder 214. In accordance with the principles of the invention, visual builder 214 includes a bean visual environment add-on 212, which allows the proxy beans 210 to appear directly on the builder's object palette. The proxy beans can therefore be manipulated in a conventional fashion using builder 214. Since the proxy beans include the parameters of the methods as attributes, the method parameters can be manipulated directly by changing the attributes of the proxy beans in order to generate a bean-based application 216. The bean-based application 216 can be tested within the visual environment by using the universal transport API 206 to access the Java objects instantiated from a selected class called the "target" class in the class and bean implementations 202. In particular, universal transport API 206 operates under control of constructor and method objects instantiated by the proxy beans 210 within bean-based application 216 to call the appropriate constructors and methods for the target class in the implementation code 202 as will be hereinafter explained in detail. The bean compiler 208, the bean visual environment add-on 212 and the universal transport API 206, function together to allow Java objects and beans to be manipulated by means of a standard visual builder 214 regardless of whether the objects were originally designed to be used as beans. The bean compiler 208 generates code for the constructor beans and method beans by subclassing and modifying two main classes, which are illustrated in FIG. 4. These classes include the ConstructorSmartBean class 402 and the MethodSmartBean class 406, each of which has a set of properties and methods. For example, the ConstructorSmartBean class 402 has properties 404, which include the properties fTypes and fParams, which, as will hereinafter be described in more detail, are used to specify the type of constructor which will be used to instantiate an object from the target class. The ConstructorSmartBean properties also include the fTransport reference and the fPropertyChange reference, which are used to reference a transport object which will be used to forward the constructor and method calls to the target class and to reference a notification object that is part of a conventional notification system. The ConstructorSmartBean class 402 also includes the plurality of methods including the targetClassConstructor( ) method, which is used to invoke the constructor of the target class, the getConstructorParameter( ) method, which is used to obtain parameters required by the targetClassConstructor( ) method and the refreshproperties( ) method, which is used to broadcast data change notifications. Similarly, the MethodSmartBean class 408 includes properties 410, including the properties fTypes, fParams, fTransport, and fPropertyChange which are analogous to the similarly-named properties in the ConstructorSmartBean class 402. In addition, the MethodSmartBean class 408 includes an additional property, fResult, which is used to hold a result returned by the associated method call. The result property can be manipulated by the putMethodResult( ), and getResult( ) methods, which are used to invoke force the result to a specified value and read the result. The MethodSmartBean class 408 also includes the targetClassConstructor( ), getTypes( ) and getParameters( ) methods, which are used in invoking a constructor in the target class and an additional method, callMethod( ), which is used to invoke the associated method. Three additional classes, the SmartConstructor class 414, the MethodEvent class 416, and the ExceptionEvent class 418 are instantiated by the constructor and method beans to encapsulate various parameters and data which are associated with the constructor and methods of the target class and exceptions generated by the constructor and methods. Objects instantiated from these latter classes are then forwarded, via the transport mechanism discussed previously, to the target class. In particular, the SmartConstructor class 414 encapsulates the parameters used in the constructor which instantiates the target class. Similarly, parameters associated with a method are encapsulated in the MethodEvent class 416 for transmission to the target object. Finally, exceptions generated by the target object are encapsulated in the ExceptionEvent class 418 for transmission back to the constructor or method bean, which initiated the constructor or method call. A routine for generating and compiling code for a constructor bean is illustrated in FIG. 5. The routine starts in step 500 and proceeds to step 502 where the Java class code is parsed. In step 504, the parsed code is examined to extract methods, fields, parameters, and comments. Next, in step 506, the code for the constructor bean is generated by subclassing the ConstructorSmartBean class 402, and, in step 508, customizing the resulting subclass. During this process the parameters of the original constructor become the bound properties of the constructor bean with the suffix "_CP" added. In this context a "bound" property is a property which generates a data change notifiaction when its value is changed. In step 510, the bean code is compiled into the constructor bean which is given a name derived from the original Java class. The routine then finishes in step 512. A similar routine is used to create and compile code for the method beans. Such a routine is shown in FIG. 6, which starts in step 600 and proceeds to step 602, in which the method code is parsed. In step 604, the parameters and comments associated with the method are extracted. Next, in step 606, the method bean code is generated by subclassing the MethodSmartBean class 408 and customizing the subclass as indicated in step 608. During this process the parameters of the original method become the bound properties of the method bean. In addition, the special bound property called "result" is created to receive the result, if any, of the method call. Next, in step 610, the bean code is compiled into the method bean with a name derived from the original method name. The routine then finishes in step 612. The beans produced by the bean compiler can be used with a conventional visual builder by means of an add-on application. Referring to FIG. 7 of the illustrative embodiment, a visual environment add-on (VEA) program 700 extends the capability of a standard Java "bean-compliant" visual builder 708 to give the user of the visual builder 708 access to methods and constructors, as beans, within any OOP code. The Java bean-compliant visual builder 708 can be any conventional visual builder, such as the Visual Age WebRunner.TM. marketed by International Business Machines Corporation, Armonk, N.Y. VEA 700 allows access by the visual builder 708 to beans contained in JAR file 702, which beans may be the beans created by the bean creator as discussed above. VEA 700 makes the method and constructor beans available to be read into the "palette" of the visual builder 708. A user can then copy beans from the palette into the visual builder "workspace" to customize and combine the beans as needed in order to create a new OOP application 710 in a conventional manner. Non-bean text-based OOP code can also be read in using the VEA's Interactive Development Environment (IDE) 712, which, in turn, uses the aforementioned bean compiler to produce beans that are usable by the visual builder 708. Referring to FIG. 8, the entire process of creating bean-based applications from original text-based OOP code is illustrated. The process starts in step 800 and proceeds to step 802 where object-oriented design code is read in to the bean creator 200. In step 804, the class code is parsed and the constructors, methods and other information discussed above is extracted. The extracted information is used to generate bean code which is then compiled, in step 806, to produce method and constructor beans. In step 808, the bean creator 200 produces the JAR and manifest files which contain the newly-produced beans. The beans are loaded into the JAR file in step 810. In step 812, the new beans are placed on the palette of a visual builder using the visual environment add-on. In step 814, the bean visual environment add-on is used, in conjunction with a visual builder 1320, to create a bean-based application. At step 816, the process is complete. Once a bean-based application is created, it interacts with the code implementing the underlying Java class by means of a universal transport API. This process is illustrated in FIG. 2 where bean-based application 216 uses universal transport API 206 to operate with class implementations 202. FIG. 9 illustrates the contents of the universal transport API 206, which include several Java interfaces 902 and 906 and implementation classes 910 and 912. The universal transport API 900 provides a framework for manipulating Java objects in a "bean-oriented" manner according to the ITransport interface 902. Interface 902 contains methods 904 which allow either local or remote objects to be constructed using both null and complex constructors (fireConstructor), methods to be called (fireMethod), and field values to be set and retrieved (setField and getField, respectively.) A null constructor is one which has no parameters whereas a complex constructor is passed parameters or arguments to construct objects. The interface 902 has two implementations: LocalTransport 910 and RemoteTransport 912. The LocalTransport implementation 910 translates application-specific messages into method calls on local Java objects (not shown.) The RemoteTransport implementation 912 is utilized in conjunction with a distributed object architecture to translate application-specific messages into method calls on remote Java objects (not shown.) If distributed object framework is used, remote objects, such as RMI objects, CORBA objects or Java objects which are not RMI or CORBA compliant can be accessed by selecting an appropriate adapter (not shown) for the object model. The universal transport API 900 also includes an IPropertyChange interface 906 which contains, among other things, a method 908 that transmits data change notifications to registered listeners in accordance with a conventional notification arrangement. In order to use the universal transport API 900, a transport object is first instantiated from the LocalTransport or the RemoteTransport class according to the location of the target class implementations. Then, a constructor bean method or method bean method which invokes a target method in the target class encapsulates the target method parameters in an object instantiated from the MethodEvent class 416 (FIG. 4) in order to permit late binding. The MethodEvent object can be serialized and transmitted over a network by the fireMethod method in the transport object to the class implementations. Exceptions, and other throwables, are encapsulated in an object created from ExceptionEvent class 418 whicah also allows for serialization. The ExceptionEvent class 418 allows exceptions which would normally be lost to be transmitted back to the client application. For example, a remote RMI-compliant object which stores employee information for a business will throw an exception when a look up error such as "Employee not found in records" occurs. In accordance with normal RMI operation, this exception will be hidden from the client by a java.RMI.RemoteException object and appear to the client as a network failure, rather than the lack of the searched instance. However, with the inventive bean creator using the API transport 206, encapsulation and serialization of the exception allows the original exception, "Employee not found in records," to propagate from the server back to the client. Constructor parameters are encapsulated in a SmartConstructor class 414, which also permits late binding and serialization. Methods which set and get field values in the target object are also serialized, but they are not encapsulated within separate classes because this encapsulation is handled by the SmartConstructor class 414. Therefore, the RemoteTransport implementation 912 allows direct access to remote native methods in a Java class without requiring a server-side wrapper class to be used. Generation of such a server-side wrapper class would require manual coding and could perturb the original code design, both of which are undesirable. FIG. 10 illustrates, in a schematic fashion, the operation of the constructor and method beans in conjunction with a transport object to manipulate the code for the target object. A single constructor bean and a single method bean are shown, but additional beans can be generated which operate in the same manner as those shown. Constructor bean 1000 includes a targetClassConstructor( ) method 1002 which is designed to invoke either a null, or a complex, constructor in the target class. The setField( ) and getField( ) methods 1004, 1006, respectively, are used to manipulate values in fields and properties of the target object. In addition, constructor bean 1000 includes two methods designated as Method 11008 and Method 21010. These methods interact with methods in the transport object 1046 to invoke methods in the Java class implementation 1048. For example, when the targetClassConstructor( ) method 1002 is invoked in constructor bean 1000, it instantiates a SmartConstructor object 1018 passing in any parameters which are required for invocation of the constructor in the target class. The SmartConstructor object 1018 is, in turn, passed to the fireConstructor( ) method 1030 in the transport object 1046. The fireConstructor( ) method 1030, in turn, invokes the constructor 1050 with the appropriate parameters in the target class implementation 1048 to construct the target object. Fields in the target object, such as field 1052 can be manipulated by means of the setField( ) method 1004 in constructor bean 1000. The setField method, in turn, invokes the setField method 1032 in the transport object 1046 in order to insert a value into field 1052 of the target object. Similarly, the value in field 1052 can be retrieved by means of the getField( ) method 1034 in transport object 1046 and returned to the getField( ) method 1006 in constructor bean 1000. If Method 1 (1008) is invoked in constructor bean 1000, it instantiates a MethodEvent object 1020 which encapsulates parameters and data associated with the method. The MethodEvent object 1020 is then passed to the fireMethod( ) method 1036 in transport object 1046. The fireMethod( ) method invokes Method 1 (1054) in the target object passing in the encapsulated parameters as necessary. An invocation of Method 2 (1010) instantiates a second MethodEvent object 1022 which is then passed to the fireMethod( ) method 1036 to invoke Method 2 (1056) in the manner previously described. If either of the methods 1054 or 1056 generates an exception or other throwable, the throwable is returned via the returnThrowable( ) method 1038 in transport object 1046 which, in turn, creates an ExceptionEvent object 1024 encapsulating the exception parameters including any exception text. The ExceptionEvent object is then returned to the constructor bean 1000. The method bean 1012 operates in a similar manner. It also contains a targetClassConstructor( ) method 1014 which, in turn, instantiates a SmartConstructor object 1026 that can be applied to the fireConstructor( ) method 1040 in transport object 1046. Method 1040 may be the same as method 1030, but is shown separately for clarity. This operation constructs the target object if it is not already constructed Similarly, an invocation of the callMethod( ) method 1016 in method bean 1012 causes a MethodEvent object 1028 to be instantiated, which MethodEvent object encapsulates the parameters of the method. The MethodEvent object 1028 is, in turn, passed to a fireMethod( ) method 1042 (which may be the same as method 1036) in the transport object 1046 which, in turn, invokes the proper method in the target object. The result generated by an invoked method is returned by the returnResult( ) method 1044 in transport object 1046 which transports the result to the Result property 1017 in method bean 1012. The following is an example of the operation of the bean compiler. In this example the target class is a Java class called Accountlnfo. The class contains the account owner's first and last names and retrieves information about an account owner, including the owner's date of birth (DOB), account balance and type, etc. The COM.test.Accountlnfo class has a class definition as follows:
package COM.test;
public class AccountInfo
{
public String firstName, lastName;
public AccountInfo(String SSN)
throws Exception
public String getDOB
{. . .}
public String getAccountType()
{. . .}
public Float getBalance()
{. . .}
public void setBalance (Float bal)
{. . .}
public String createReport (boolean history)
{. . .}
}
Using the inventive bean compiler, two classes would be generated based upon this class definition. The first generated class is a constructor bean for the class constructor: public Accountinfo (String SSN). The skeleton of the constructor bean class would be as illustrated in the Java code snippet which follows:
package COM.test;
public class AccountInfoSBC1
extends ConstructorSmartBean
implements java.io.Serializable
{
// Constructor Type array
private Class fTypes [] = {String.class};
// Constructor Parameters
private Object fParams [] = new Object [1];
. . .
}
Note that this constructor bean class inherits from the constructor bean base class, ConstructorSmartBean, and is serializable. The "SBC1" postfix indicates that this is constructor number 1 for a constructor bean. The class also contains two private fields. The first field fTypes is used to locate the correct constructor for the target object. The second field, fParams, is used to hold and pass the constructor parameters, which appear in this constructor bean as properties. Next, the constructor for the AccountlnforSBC1 constructor bean class is created as illustrated in the Java code snippet below:
public AccountInfoSBC1() throws Exception
{
super();
try
{
setConstructor
(new SmartConstructor("COM.test.AccountInfo",fTypes));
}
catch (Exception e)
{
. . .
}
}
This constructor instantiates a SmartConstructor object for the eventual target class COM.test.AccountInfo. Next, code to handle the retrieval of the constructor parameters, as well as property change notifications for the target object's original fields is generated as shown in the following Java code snippet:
public Object [ ] getConstructorParameters()
{return fParams;}
public void refreshProperties()
{
fPropertyChange.firePropertyChange
("lastName", null, getLastName());
fPropertyChange.firePropertyChange
("firstName", null, getFirstName());
fPropertyChange.firePropertyChange
("DOB", null, getDOB());
fPropertyChange.firePropertyChange
("accountType", null, getAccount Type());
fPropertyChange.firePropertyChange
("balance", null, getBalance());
}
Note the reference fPropertyChange to a data notification object which transmits the data change to all interested "listener" parties. Next, code to handle the getting and setting of properties originally specified as public fields on the target object is created. The following code snippet illustrates the code which manipulates the target object lastName field. The code for other fields is analogous. This code uses a reference fTransport to a transport object which conveys the object invocations to the target object:
public String getLastName()
{
try
{
return (String) fTransport.getField("lastName");
}
catch (Throwable t)
{return null;}
}
public void setLastName(String data)
{
try
{
Object old = fTransport.getRecentField ("lastName");
fTransport.setField("lastName", data);
fPropertyChange.firePropertyChange("lastName, old, data);
}
catch (Throwable t)
{return;}
}
Note that a property change notification is sent when the value of the lastName field changes indicating that this is a bound field. Since certain methods of the target class are treated as constructor bean properties because of the set/get design patterns they express, they are handled as illustrated in the following code snippet. Only the getBalance( ) and setBalance methods are illustrated, other methods are treated in a similar manner:
public Float getBalance ()
{
try
{
Class types[ ] = {}
Object params[ ] =- {}
MethodEvent method = new MethodEvent
(this, "getBalance", types, params, true);
return (Float) fTransport.fireMethod(method);
}
catch (Throwable t)
{return null;}
}
public void SetBalance (Float data)
{
try
{
Object old = fTransport.getRecentField("balance");
Class types [ ] = {Float.class};
Object params [ ] = {bal};
MethodEvent method = new MethodEvent
(this, "setBalance", types, params, true);
fTransport.fireMethod(method);
fPropertyChange.firePropertyChange("balance", old, bal);
return;
}
catch (Throwable t)
{return;}
}
The inventive bean compiler also generates a bean for each method in the target class. The bean has the same name as the method with a postfix "SBM." The "SBM" postfix indicates this is a method bean. A partial class definition for the createReport method in the sample target class is illustrated by the following Java code snippet:
public class CreateReportSBM
extends MethodSmartBean
{
private String fResult=null;
private Class fTypes[]={Boolean.class};
private Object fParams[] = new Object [1];
}
As with the aforementioned constructor bean, this class also contains two private fields. The first field fTypes is used to locate the correct constructor for the target object. The second field, fParams, is used to hold and pass the constructor parameters, which appear in this bean as properties. This method bean class also has a third private, field, namely the fResult field used to hold the result from the method call. The constructor for this method Bean is generated as follows:
public CreateReportSBM()
super ("createReport");
fParams[0] = Boolean.FALSE;
}
This constructor passes the name of the target object method to its parent's constructor. It also initializes the parameters array. Note that since the parameter for the method is a primitive type, the compiler must be intelligent enough to convert to the corresponding Object type, as well as to supply a default value. The illustrative method bean also contains the next code section which is similar for any method bean:
public void putMethodResult (Object result)
{
fResult = (String) result;
fPropertyChange.firePropertyChange("result", null, fResult);
}
public String getResult()
{
return fResult;
}
The first method, putMethodResult, allows the parent class to set the result value returned from a method call, and also allows the method bean to generate a data change notification when the result value is changed. The second method merely allows the result to be treated as a readable property. Note that for each method bean, the result type may be different. The following two additional methods in the method bean code allow the parent class to retrieve the method types and method parameters:
public Class [] getTypes()
{
return fTypes;
}
public Object [] getParameters()
{
return fParams;
}
The following additional methods handle the parameters of the target method itself, while treating these parameters as bound properties of the method bean.
public boolean getHistory ()
{
return
((Boolean)fParams[0]).booleanValue();
}
public void setHistory(boolean data)
{
Object old = fParams [0];
fParams [0] = new Boolean (data):
fPropertyChange.firePropertyChange("History", old, fParams[0]);
}
Note again the primitive to corresponding-data-type translation. This is needed for fields of types int, short, long, boolean, byte, char, float, and double. As previously mentioned, once the proxy beans are constructed, they can be displayed, manipulated and tested by means of a bean tester that is based on conventional visual builder. The screen display of an illustrative bean tester which is based on a conventional bean-enabled visual builder is illustrated in FIG. 11. As an illustrative example, the aforementioned visual builder is the WebRunner.RTM. visual builder developed and sold by the International Business Machines corporation. It will be apparent to those skilled in the art that other bean-enabled visual builders with similar screen displays could also be used without departing from the spirit and scope of the invention. The screen display 1100 of such a builder includes a menu bar 1110 which provides a user with access to operations and properties associated with the bean in the workspace 1140. For example, the File menu would allow a user to open or close a bean file or exit the visual builder application. The Edit menu would allow a user to change properties of a bean, for example, the bean font or color scheme. A toolbar 1120 is also part of the GUI and provides a shortcut method for a user to access some of the same functionality that is available through use of the menus. The toolbar 1120 is typically comprised of toolbar buttons which represent functions, for example, opening a file and changing font attributes. When the visual builder 1100 is launched, a bean palette window 1125 is opened which displays the beans 1130 available for manipulation. A palette title bar 1135 displays for the user which palette is open for use. For example, in FIG. 11, the title bar 1135 indicates that the "Default" palette is in use. A user may also build custom palettes tailored for particular purposes and use one of those rather than the default, if desired. In order to appear in the palette window 1125, each bean must interface with the visual builder by using the builders internal interface. The visual environment add-on 700 (FIG. 7) allows proxy beans which are generated as discussed above to appear on a custom palette in the palette window 1125 by interfacing the beans with the builders interface. A workspace panel window 1140 is opened, generally in the center portion of the visual builder, and allows beans and objects to be visually selected and manipulated. A third panel or window is also opened in the illustrative embodiment, called the properties window 1155. The properties window 1155 displays to the user properties 1160 and the corresponding property value 1165 associated with a bean selected in the workspace window 1140. For example, a database (DB) bean is shown in the workspace 1140. The property list 1160 shows that there is a "label" property associated with the bean and the value list 1165 shows the text of the label to be "NEW DB BEAN", which is also reflected in the workspace 1150. In the case of proxy beans, the property list 1160 would display the proxy bean properties including those properties which represent the parameters of the underlying methods. A component can be customized to create a new component using the visual builder. To accomplish this, an existing component icon is dragged from the palette 1125 into the workspace 1140. Once dragged into the palette, the component, which is the original source of what will become the customized component or part of a composite component, is selected so that its properties are reflected in the properties panel 1155. To customize the component, property values 1165 are then edited using either or a combination of the menus 1110 and toolbar buttons 1120. In the illustrative embodiment, the File menu contains a "Save As Bean" menu item option which allows the modified code to be saved as a new component. This save operation changes the original source component, represented as an icon in the palette 1125, to reflect the customization. FIG. 12 discloses the overall steps in an illustrative method with which a composite component can be created and added to a visual builder palette using the component, or bean, tester. In general, a composite bean is created by selecting a set of beans and then "wiring" the beans together so that events generated by one bean are responded to by other beans in the composite and selected properties are bound together. Finally, the constructed bean can be tested using the universal transport mechanism discussed above and controlling the universal transport mechanism by the composite bean as will be discussed below. The method for creating a composite bean starts in step 1200, where it is assumed that the computer 100 is running and the visual builder has been launched and proceeds to step 1210. In step 1210, an operator selects components from the palette 1125 which are to comprise the ultimate composite component. In the illustrative embodiment, the components can be selected from the palette 1125 by holding down the "shift" key and clicking on each component icon in turn from the palette 1125, as desired. The operator then releases the "shift" key and places the mouse cursor over any of the now highlighted component icons, depresses and holds down the mouse button, and "drags" the group of icons into the workspace panel 1140. With the components in the workspace, the user can design and implement a component layout using, for example, alignment icons in the toolbar 1120. The user can then "wire" the components together to create a single composite component by setting up event handling among the components (step 1220), or by binding properties among components (step 1230.) Depending on the objectives of the creator of the composite component, some or all of the wiring may be done by event handling and some or all of the wiring may by performed by binding properties. These latter steps are discussed in more detail below. In step 1240, the new component can be saved as a composite component. Step 1240 incorporates the activities of specifying a directory and creating the necessary code files associated with the component. Once the component has been saved to a directory and associated source code created, the component can be tested as set forth in step 1250. Once the bean operates as desired, the component can be loaded into a palette as set forth in step 1260, so that icon representing the component appears in the palette 1125 for use in creating objects or other composite components. The process then ends in step 1270. FIGS. 13, 14 and 15 illustrate screen displays and steps in illustrative methods for handling events among components which exist within a composite bean. These illustrative methods are an expansion of step 1220 of FIG. 12. In the particular illustrative embodiment, event handling can be arranged in either a "Layout" or "Visual Connect" mode. The steps involved in the Layout Mode method are illustrated in FIG. 13, whereas the steps involved in the Visual Connect mode are illustrated in FIG. 15. To establish event handling among components within a composite component in the Layout Mode, the layout mode is first entered by selecting "Layout" from the mode menu, in step 1300. In step 1305, a "source" component is selected by mouse clicking on the icon representing it in the workspace 1140. The source component will include methods to generate event messages. After wiring, these event messages are sent to event listeners, i.e. objects created from "target" components. Next, in step 1310, a "Connect Events" item is selected from the Connect Menu in order to open a Connect Events dialog box (illustrated in FIG. 14). When the Connect Events dialog box is opened, the source component is displayed in the source component list 1401 (for example, a button component 1403.) The user can also select other source components at this time. In the Connect Events dialog box 1400, in step 1315, the user can select an event set from a list 1402 of the events generated by the source component (for example, mouse events 1404). Once an event set is selected, the events generated by the device are displayed in the source event list 1406 and the source event type from a list 1406 (for example, mouse clicked 1408),. Next, in step 1320, also from the Connect Events dialog box 1400, the user can select a target component from list 1410 which includes the components represented by icons displayed in the workspace 1140 (for example,. a chart 1412) which can handle events. Next, in step 1325, a target method from list 1414 associated with the target component (for example, a hide method 1416) is selected. In step 1330, the "Apply" button 1418 located in the Connect Events dialog box 1400 can be selected to complete the wiring of the event. For example, with the selections shown in FIG. 14, when a source button is selected by placing the cursor over the source button and depressing the mouse button, an event notification will be sent to an object created from the target component class. This event notification will cause the target object to hide its display when the mouse is clicked on the button. In step 1335, with the connections now "applied", the "close" button 1420 of the Connect Events dialog box can be selected to close the box and hide its display. In step 1340, "wires" are displayed between the icons in the workspace to visually demonstrate the connections which have just been made. Referring to FIG. 15, the steps in a method for arranging event handling among components which exist within a composite component using the Visual Connect mode are illustrated. As previously mentioned, this method is an expansion of step 1220 of FIG. 12 and serves as an alternative to the method of FIG. 13. The method starts in step 1500 and proceeds to step 1502 where the user enters the Visual Connect mode by choosing a "Visual Connect" item from the mode menu. The user then selects a source component, in step 1504, from the workspace 1140 by mouse clicking on it. Event "handles" are displayed on the selected source component in step 1506. In the illustrative embodiment, the event handles are displayed as circles on the periphery of the component. An association is created between the source component and a target component in step 1508 when the user clicks on one of the source component event handles, drags the source component to the target component and drops the source component on the target component. At this point, as set forth in step 1510, the Connect Events dialog box 1400 is opened as previously discussed with the exception that the source component and the target component are already selected when the box opens. Next, in step 1512, the Connect Events dialog box 1400 is used to select the event set and source event type for the source component using the lists 1402 and 1406 as discussed previously. In step 1514, the target method which will handle the event is selected from list 1414. In step 1516, the event is "wired" by selecting the "Apply" button 1418 from the Connect Events dialog box. The user can then select the "Close" button 1420 in the Connect Events dialog box 1400 to close the box 1400 as set forth in step 1518. In step 1520, in the workspace, "wiring" lines are displayed between the selected components. The method then ends in step 1522. The visual builder generates an adapter class to implement the event handling. This adapter class contains a method that registers itself as a listener for the selected event in the source bean. Another method in the adapter class invokes the selected method of the target bean when the selected event occurs in the source bean. The event notification mechanism is conventional and will not be discussed in detail hereinafter. When the target bean is a proxy bean, the selected method can be invoked by instantiating the EventMethod class and using the fireMethod( ) method in the universal transport mechanism as discussed above with respect to FIG. 10. Referring to FIGS. 16, 17 and 18, a screen display and steps in methods for binding properties between components within a composite component are illustrated. With these methods a first property in one bean can be bound to a second property in another bean so that changes in the first property are automatically propagated across one or more beans. The beans can be of the same type or different types as long as the property has the same value type. As with event handling, the properties can be bound between components in either the "Layout" or "Visual Connect" mode of the illustrative embodiment. FIG. 16 illustrates the steps involved in binding properties in the Layout Mode whereas FIG. 18 illustrates the steps in the Visual Connect Mode. Both methods are alternative expansions of step 1230 in FIG. 12. FIG. 17 illustrates a dialog box display used in the two methods. The Layout Mode operation is illustrated in FIG. 16 which starts in step 1600 and proceeds to step 1602. To bind properties in the Layout Mode, the "Layout" item is selected from the mode menu, in step 1602. Next, in step 1604, an icon representing the source component is selected from the icons previously dragged into the workspace 1140. In step 1606, a Bind Properties dialog box 1700 (FIG. 17) is opened when a user selects the "Bind Properties" item from the Connect menu. Next, in step 1608, the source property (for example, foreground color 1708) which will be bound is selected from list 1706. In step 1610, the target component (for example, a chart 1712) is selected from the list 1710 which contains a list of the components represented by icons in the workspace 1140. When the target is selected a list of its properties appears in list 1714. With the target component chosen, in step 1612, the target property (for example. background color 1716) to which the source property will be bound is selected. In step 1614, the "Apply" button 1718 is selected to complete the binding. The Bind Properties dialog box 1700 is closed by selecting the "Close" button 1720 in step 1616. In the workspace 1140, connections are displayed in step 1618 between the source and target components indicate the binding. The method then ends in step 1620. In the particular binding illustrated in FIG. 17 when the foreground color of the source button is changed, for example, the background color of the target chart will also change. FIG. 18 illustrates the steps in a method for binding properties among components which exist within a composite component using the Visual Connect mode. As previously mentioned, this method is an expansion of step 1230 of FIG. 12 and serves as an alternative to the method of FIG. 16. The method starts in step 1800 and proceeds to step 1802 where the user enters the Visual Connect mode by choosing a "Visual Connect" item from the mode menu. The user then selects a source component, in step 1804, from the workspace 1140 by mouse clicking on it. Event "handles" are displayed on the selected source component in step 1806. In the illustrative embodiment, the event handles are displayed as circles on the periphery of the component. An association is created between the source component and a target component in step 1808 when the user clicks on one of the source component event handles, drags the source component to the target component and drops the source component on the target component. At this point, as set forth in step 1810, the Bind Properties dialog box 1700 is opened as previously discussed with the exception that the source component and the target component are already selected when the box opens. Next, in step 1812, the Bind Properties dialog box 1700 is used to select the event set and source event type for the source component using the lists 1702 and 1706 as discussed previously. In step 1814, the target property to be bound is selected from list 1714. In step 1816, the event is "wired" by selecting the "Apply" button 1718 from the Bind Properties dialog box. The user can then select the "Close" button 1720 in the Bind Properties dialog box 1700 to close the box 1700 as set forth in step 1818. In step 1820, in the workspace, "wiring" lines are displayed between the selected components. The method then ends in step 1822. As previously mentioned, proxy beans encapsulate the parameters of methods as properties. In accordance with the principles of the invention, by binding the properties of method proxy beans to other component properties, it is possible to set and change the method parameters at runtime, and, particularly, during testing. This capability allows for complete testing of the component beans. FIG. 19 depicts a functional flow of a method for saving a new component in accordance with the illustrative embodiment. The save process includes the process of creating the necessary files associated with the component and expands step 1240 of FIG. 12. The method begins in step 1900 and proceeds to step 1902 where the new component is saved as a composite bean by selecting the "Save As Composite Bean" item from the File menu. Choosing the save command causes a dialog box to be opened as set forth in step 1904. The dialog box prompts the user for necessary information regarding execution of the save command. In step 1906, using the dialog box the user specifies, the project and package names for the new composite component and the directory where the component and related files are to be saved. With that information specified, in step 1908, the bean tester creates the source code for the composite component, and creates manifest and JAR files for the component in step 1910. In step 1920, the composite component is associated with an icon. The process then finishes in step 1914. FIG. 20 discloses a bean testing method which utilizes the aforementioned visual builder. While this method can be a standalone process, it is also representative of an expansion of step 1250 of FIG. 12. The beans to be tested could have been created from a number of different programming means. In any case the bean is processed by the bean compiler 300, discussed earlier in connection with FIG. 3 to create proxy beans for the methods. The proxy beans are then wired together to create a composite bean as discussed above. The composite bean can be tested and then added to a visual builder palette for use in creating objects or other composite beans. Testing a composite bean typically involves testing the operation of its methods and bound properties, which, as discussed above include the parameters of the methods. In step 2000, the process is started with the assumption that the computer 100 is running, the visual builder application is running, and a user has a bean, which could be a composite bean that is composed of proxy beans, for testing residing in memory and which appears on the palette of the visual builder. In step 2002, the bean to be tested is loaded into the tester described above using the visual environment add-on, also as discussed above. Next, in step 2004, the bean is displayed in the workspace window by selecting it from the palette. At this point the bean can be edited and modified. In step 2006, the bean can be run by choosing the "Run" item from the tester Mode menu 1110 or by clicking on the Run toolbar button icon in the toolbar 1120. As previously mentioned, when the methods of proxy beans are invoked, they use the universal transport mechanism to invoke the actual component code in order to test the method as set forth in step 2008. Further, as discussed previously, the method parameters of the original bean are exposed by the proxy components created from the methods of that bean. Consequently, each method can be tested fully. Next, in step 2010, the bean is checked to ascertain if it is operating properly. In some cases the result of the test can be ascertained visually. For example, if the bean responds to an event by running a graphics image, the image should be displayed. In another example, if the bean had bound properties associated with it, like simultaneously changing the background color of objects created from the bean, the bound property could also be tested by selecting and changing the background color of one bean using the bean tester properties panel and then inspecting whether the background color of the other bean with bound properties also changed. In other cases property values must be checked. In step 2012, if the bean passes the test, the operator may proceed to load the bean into a visual builder palette as set forth in step 2016. The method then finishes in step 2018. If the bean did not pass the test, the operator may then choose to edit the bean as set forth in step 2014. The method then proceeds back to step 2006 where the bean is rerun to retest it. A software implementation of the above-described embodiment may comprise a series of computer instructions either fixed on a tangible medium, such as a computer readable media, e.g. a diskette, a CD-ROM, a ROM memory, or a fixed disk, or transmissible to a computer system, via a modem or other interface device over a medium. The medium can be either a tangible medium, including, but not limited to, optical or analog communications lines, or may be implemented with wireless techniques, including but not limited to microwave, infrared or other transmission techniques. It may also be the Internet. The series of computer instructions embodies all or part of the functionality previously described herein with respect to the invention. Those skilled in the art will appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including, but not limited to, semiconductor, magnetic, optical or other memory devices, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, microwave, or other transmission technologies. It is contemplated that such a computer program product may be distributed as a removable media with accompanying printed or electronic documentation, e.g., shrink wrapped software, pre-loaded with a computer system, e.g., on system ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, e.g., the Internet or World Wide Web. Although an exemplary embodiment of the invention has been disclosed, it will be apparent to those skilled in the art that various changes and modifications can be made which will achieve some of the advantages of the invention without departing from the spirit and scope of the invention. For example, it will be obvious to those reasonably skilled in the art that, although the description was directed to a particular language, other object-oriented languages would also be suitable for the invention. Similarly, although a particular hardware system and operating system is described, other hardware and operating system software could be used in the same manner as that described. Other aspects, such as the specific instructions utilized to achieve a particular function, as well as other modifications to the inventive concept are intended to be covered by the appended claims.
|
Same subclass Same class Consider this |
||||||||||