1. Field of the Invention
Preferred embodiments provide a method, system, and program for implementing a user interface in an object, such as a Document Model Object (DOM) object.
2. Description of the Related Art
One of the purposes of the Java** programming language is to allow programmers to develop applications that can execute across operating system platforms. The Java language accomplishes the cross-platform implementation by providing an added layer of execution between the underlying operating system and programs written in the Java computer language. The Java Platform converts Java source code (.Java files) to bytecodes (.class files), which are machine independent representations of a Java class. Thus, the same bytecodes would be created for all operating system platforms. The bytecodes are then inputted to a Java Virtual Machine program that converts the byte codes to the object code in the native machine language of the operating system on which the Java Virtual Machine is installed. There is a platform-specific Java Virtual Machine program for each platform on which Java programs can execute.
** Java and JDBC are trademarks of Sun Microsystems, Inc.; Microsoft is a registered trademark of Microsoft Corporation; OS/2 is a registered trademark of International Business Machines Corporation; Netscape is a registered trademark and Netscape Communicator, Netscape Navigator, Mozilla are trademarks of Netscape Communications Corporation. 
All Java programs utilize Java specific toolkits to implement a graphical user interface for Java, which is based on the Java look-and-feel. The purported goal of the Java look-and-feel is to provide a distinctive platform-independent appearance and standard behavior. To implement the Java look-and-feel, Sun Microsystems, Inc. provides the Abstract Window Toolkit (AWT) and Swing components which are classes that implement a Java graphical user interface (GUI). One drawback to implementing the GUI in the Java look-and-feel is that the Java look-and-feel is significantly different from the look-and-feel implemented in the native operating system, such as Windows, OS/2, etc.** Thus, users running a Java program on a particular operating system platform will have to use the Java GUI interface which differs from the operating system GUI interface to which they are accustomed. These differences can discourage users from adopting Java applications, especially when other application programs, such as those implemented in C++, all use the same native API function calls to implement the native operating system GUI components. Sun Microsystems, Inc. addresses this problem by continually trying to incorporate elements of common operating system platforms into the Java look-and-feel. However, this approach consistently leaves the Java look-and-feel a step behind what is currently implemented in the operating system platform.
** Java and JDBC are trademarks of Sun Microsystems, Inc.; Microsoft is a registered trademark of Microsoft Corporation; OS/2 is a registered trademark of International Business Machines Corporation; Netscape is a registered trademark and Netscape Communicator, Netscape Navigator, Mozilla are trademarks of Netscape Communications Corporation. 
Another drawback with the Java GUI interface is that the Java interface must be converted to Java bytecodes and then to native operating system commands using the Java Virtual Machine layer. This extra layer of compilation for the user interface slows down the execution of Java programs on the native operating system. Non-java programs that use the native operating system API function calls to implement the GUI do not have this problem as they directly call the native operating system API functions that implement the GUI and do not need an additional layer of conversion as in the case of Java.
Another drawback with Java is that Java application programs, including Java Applets that often execute within a Java enabled HTML web browser, are confined to executing within the Java area of execution. An executing Java program cannot interact with other components and objects in the operating system. For instance, a Java applet executing within a web browser cannot access tables and data outside of the area of execution of the applet, even if such tables are in the HTML document displayed in the web browser.
To address this problem, Microsoft has provided a mechanism to allow Java applications to access the Microsoft operating system component objects, referred to as COM objects. COM objects are used to store reusable software components. A component is a reusable piece of software in binary form that can easily interface with components from different vendors. For example, a spell checking component can be used with word processing programs from different programs.
Component objects are accessed through interfaces. An interface is a strongly-typed group of semantically-related functions, also called xe2x80x9cinterface member functions.xe2x80x9d The interface is defined according to its use and behavior. A client system or process calls the interface to access the implementation of an object and requests the object""s services. The interface includes member functions that act upon the object. The client maintains a pointer to the interface which is, in actuality, a pointer to an array of pointers to the object""s implementations of the interface member functions.
When calling member functions, the caller would construct a COM API (application program interface) with an argument which is the pointer to the object instance itself. The interface would then access the code in the object to carry out a particular operation or set of operations. Further details of the Microsoft Corporation implementation of COM is described in the publication xe2x80x9cThe Component Object Model Specification, Draft Version 0.9xe2x80x9d (Copyright 1992-95 Microsoft Corporation), which publication is incorporated herein by reference in its entirety.
Microsoft Corporation currently provides an architecture to make Windows COM objects available to Java programs. The Microsoft Java Virtual Machine (VM) internally uses a Java-Callable Wrapper (JCW) to represent a COM object in Java. JCWs appear to Java developers as generic Java objects. JCWs are programmatically manipulated in exactly the same way as any regular Java object. The JCW contains all the information necessary for the Microsoft VM to manipulate the underlying COM object. COM objects can be used in the same manner as Java objects because the Microsoft VM exposes COM objects as Java objects. Microsoft further provides J/Direct to access Windows API COM functions to create new instances of COM classes. J/Direct provides classes that map COM functions to Java calls. Further details of how Microsoft provides Java applications access to COM objects are described in the publications xe2x80x9cUsing COM Objects from Java,xe2x80x9d by Chad Verbowski (Copyright Microsoft January 1999) and xe2x80x9cIntegrating Java and Cornxe2x80x9d, by Chad Verbowski (Copyright Microsoft, January 1999), which publications are incorporated herein by reference in their entirety.
By using J/Direct to expose COM objects to Java applications, J/Direct allows the Java application to access objects outside of the area of execution of the Java application. However, Microsoft""s J/Direct system is limited to the Microsoft operating systems and Microsoft Java Virtual Machine. Microsoft""s proprietary approach defeats the Java goal of allowing the application program to execute across different operating system platforms. A Java developer who writes a Java application using the J/Direct interfaces to COM objects is limited to the Microsoft Windows platform and cannot access the COM version of objects in other operating systems, thus defeating the cross-platform goal of Java.
Thus, there is a need in the art for an improved platform independent technology to allow Java applications to access operating system components and objects outside of the area of execution of the Java program to take advantage of the objects and interfaces available in different operating system platforms.
There is also a need in the art to allow Java applications to use more commonly used graphical user interface (GUI) components, other than the GUI components offered in Java tool kits, such as AWT.
To overcome the limitations in the prior art described above, preferred embodiments disclose a method, system, and program for implementing components of a user interface as an object. A user interface is implemented in a first user interface program object including elements compatible with a first user interface program. A standard application program interface (API) calling a first standard object to create a second standard object as an element of the first standard object is received. The standard API is a member of a set of standard APIs, such as the W3C APIs. A second user interface program API is generated to create a second user interface program object corresponding to the second standard object. The second user interface program object is embedded as an element in the first user interface program object.
In further embodiments, the second standard object is associated with the second user interface program object. The second standard object is returned to a program including standard API calls to the second standard object.
In still further embodiments, the first user interface program may comprise a browser program and the second user interface program comprises a plug-in program to the browser program. Further, the set of standard APIs may comprise the W3C DOM APIs and the first and second user interface programs implement the W3C DOM.
Preferred embodiments make available standard API interfaces, such as those specified in the W3C DOM specifications, for use with programs written in cross-platform languages, such as Java, to allow the application program to manipulate objects and interfaces in a user interface program, such as a Mozilla browser or Internet Explorer, that implements the standard API interfaces. This extends the Java environment by making any object accessible to the user interface program accessible to the Java application program. The preferred embodiments take advantage of the fact that many user interface programs, such as the common web browsers, implement the W3C DOM specification and API interfaces. Preferred embodiments allow objects in the application program to map to a corresponding implementation of that object in the user interface program. By providing a mapping of the W3C interfaces to the specific user interface implementation and the application program objects to the user interface objects, the preferred embodiments allow Java developers to utilize W3C standard interfaces to access objects in the user interface program to allow the Java program to use the user interface.
By making user interface objects accessible to the Java program, the Java program can implement its user interface using the interface component objects of the user interface program. This allows a Java program user interface to have the same xe2x80x9clook-and-feelxe2x80x9d as the user interface program, e.g., Internet web browser, as the Java program is ultimately using the same user interface component objects utilized by the user interface program. Because the translator programs of the preferred embodiments allow the Java application program and standard API interfaces to execute across different operating system platforms, preferred embodiments provide a mechanism for a Java program to access and manipulate user interface and operating system objects across operating system platforms