System, Method and Article of Manufacture for Creating an Object Oriented Component Having Multiple Bidirectional Ports for Use in Association With a Java Application or Applet

Portions of this patent application include materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document itself, or of the patent application, as it appears in the files of the United States Patent and Trademark Office, but otherwise reserves all copyright rights whatsoever in such included copyrighted materials.

This invention generally relates to improvements in computer systems and, more particularly, to an improved object oriented component system having multiple bidirectional ports, which ports can be set to mirror the input type and value applied to one of the ports.

Object oriented based programming (OOP) is probably the most arresting, stimulating and intriguing aspect of programming in today's software world. Although it has been available for some time in languages such as Simula and SmallTalk and recently in C++ and Java, OOP has only recently taken hold as the hoped for solution to closing the gap between the theoretical capability of hardware and the general performance of software while simultaneously solving problems left over from prior software development approaches.

In the past, programming development which began with a single procedure approach, evolved to modular programming, went from there to structured programming and then branched off into computer aided software engineering (CASE) and program generators. All of these methodologies, while solving some or many of the difficulties inherent in prior approaches, introduced their own limitations and inefficiencies. Program bloat, data corruption and "spaghetti" code were but a few of the problems that were caused or left unsolved by the aforementioned software development approaches.

In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way.

The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still "sits on top of" the system.

Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application.

Into to this breach, entered Object-Oriented Programming (OOP) techniques which involve the definition, creation, use and destruction of "objects." Objects are self-sufficient software entities comprising data elements and routines, or functions, sometimes called methods, which are used to manipulate the data elements. The object's data and related functions are treated by the software as an entity and they can be created, used and deleted as if they were a unitary item. Together, the data and functions enable objects to model virtually any real-world entity in terms of its characteristics, which can be represented by the data elements, and its behavior, which can be represented by its data manipulation functions. In this way, objects can model concrete things like people and computers, and they can also model abstract concepts like numbers or geometrical designs.

Objects are defined by creating "classes" which are not per se objects themselves, but which act as templates that instruct a compiler how to construct an actual object. A class may, for example, specify the number and type of data variables and the steps involved in the functions which manipulate the data. An object is actually created in the program by means of a special function called a constructor which uses the corresponding class definition and additional information, such as arguments provided during object creation, to construct and initialize the object and its data members. Likewise objects are destroyed by a special function called a destructor. Objects are employed by using their data and invoking their functions to accomplish a task.

The concept of an object is predicated on and the benefits of object-oriented programming techniques arise from the use of three basic principles; those of encapsulation, polymorphism and inheritance. These principles work in conjunction with objects as described below. It is noteworthy to distinguish between an object and a class of objects. A class is a type definition or template used to create objects in programs. The objects so created are then merely each a single instance of the class of objects, which is often just called a class. A class has no memory or behavior of its own except to serve as the blueprint from which objects can be created.

An object is a self-sufficient component that includes both data and function. An object is of the same type as the class from which it has been derived. Objects are said to be instantations of their class and use memory for their data and functions, unlike the class template itself which does not.

Objects can be designed to hide, or encapsulate, all, or a portion of, their internal data structure and internal functions. OOP also allows a programmer to create an object that is a part of another object and thereby define assemblies and sub-assemblies, as may be required by a program or the situation or item it is modeling.

More particularly, during program design, a program developer can define objects in which all or some of the data variables and all or some of the related functions are considered "private" or made available for use only by the object itself. Other data or functions can be declared "public" or available for use by other objects or programs.

Further, access to private variables by other objects or programs can be controlled by defining public functions for an object which access the object's private data. The public functions form a controlled and consistent interface between the private data and the "outside" world. Any attempt to write program code which directly accesses the private variables causes the compiler to generate an error during program compilation which error stops the compilation process and prevents the program from being run.

Polymorphism is capability to conceal the different implementations behind a common interface. This means that separate objects of the same class can have different internal functions and data and implement received messages differently, but still produce uniform or consistent results. For example, an addition function may be defined as variable A plus variable B (A+B) and this same format can be used whether variables A and B represent numbers, characters or monetary units such as dollars and cents. However, the actual program code which performs the addition may differ widely depending on the type of variables that comprise A and B. Polymorphism allows three separate objects that employ different function definitions to be written, one for each type of variable (numbers, characters and dollars). After the functions have been defined, a program can later refer to the addition function by its common format (A+B) and, during compilation, the OOP based compiler will determine which of the three functions needs to be used by examining the variable types. The compiler will then substitute the proper function code in the object it compiles. Polymorphism allows similar functions that produce analogous results to be "grouped" in the program source code to produce a more logical and clearer program flow.

The third principle which underlies object-oriented programming is that of inheritance. Inheritance allows program developers to easily reuse pre-existing programs or portions thereof to avoid creating software from scratch. The principle of inheritance allows a software developer to declare classes (and the objects which are later created from them) as related. Specifically, classes may be designated as subclasses of base classes. A subclass "inherits" and has access to all of the public functions of its base classes just as if these functions appeared in the subclass. Alternatively, a subclass can override some or all of its inherited functions merely by defining a new function with the same form (overriding or modification does not alter the function in the base class, but merely modifies the use of the function in the subclass). The creation of a new subclass which has some of the functionality (with selective modification) of another class allows software developers to easily customize existing code to meet their particular needs while still taking advantage of reusing prior, usually debugged and well behaved code, rather than having to write and qualify new code of their own.

By utilizing the concepts of encapsulation, inheritance and polymorphism, an object can be made to accurately and independently represent just about anything in our world, real or simulated. In fact, the limits of our logical perceptions of such representation is the only restraint on the kinds of things that can become objects in object-oriented software. Some typical categories are as follows:

Objects can represent physical objects, such as airplanes in an air traffic control system, components in a stereo or television system, balance sheet and income statement elements in a fundamental analysis company business model, or stars in the simulated night sky on display at a planetarium;

Objects can represent elements of the computer-user environment such as windows, scrollbars, sliders, menus or other graphical items;

An object can represent a collection of data, such as a personnel file or a table of the latitudes and longitudes of cities; or

An object can represent user-defined data types such as time, angles, and complex numbers, functions or points on the plane.

While object-oriented programming offers significant improvements over other programming concepts in the design and development of programs, program development and program development tools, even within an OOP environment, still require significant outlays of time and effort. This is particularly true where the developer has to write a significant amount of code from scratch and is unable to take full advantage of the benefits of object oriented programming. The ability of development tools to negate or reduce the need to write code in the traditional sense and permit a developer to concentrate on development and visually interact with an enriched development tool is the focus and goal of the present invention.

It is usually the case that proponents of a particular type of programming language or of a specific language of that type are best able to advance their cause and the popularity and vitality of the language type or specific implementation or dialect of the language they support.

This is usually done by directly or indirectly providing appropriate tools that make use of the language type or a specific implementation of the language easy, practical and efficient. Visual Basic and Visual C++ are examples of two current programming environments with an object oriented foundation that have been developed and made available for programmers to use in creating applications for the Windows 3.x, Windows 95 and Windows NT platforms. While Visual Basic and Visual C++ undoubtedly make program development easier by including tools, called Wizards, that relieve the programmer of the necessity to write the underlying Basic or C++ code needed to create and implement such typical graphical user interface (GUI) elements as scrollbars, sliders, buttons or dialog boxes and to define their properties, these tools do not go far enough in easing the programmer's development burden. For example, it is still necessary in either Visual Basic and Visual C++ for the programmer to write code that defines and controls the interrelationship of the elements selected for use in the program under development or to otherwise manually intercede in the object based "point and click" or "drag and drop" aspects of this program development process.

This is true in the development of general OOP based applications and also in development environments for creating Applets in a JAVA system. As the Java system and applet creation becomes more widely used, the need to simplify the development of these applications becomes desirable. In addition, while the developer in these prior art visual programming environments is given a Wizard that writes the underlying code to make an event involving one or more of the selected elements occur, the ability to simultaneously view and experience that interrelationship is not provided.

It would be desirable to provide the tool's objects or components with a component that can function as a multiplexor wherein an input applied to one of the components bidirectional ports is dynamically duplicated as an output on all the remaining ports of the component.

The present invention provides a programming environment and appropriate tools and components therefor that promote greater ease of use than is presently available in typical programming environments. and wherein an object

The present invention also provides such a multiport component having multiple bidirectional ports that can be set to duplicate an input thereto on its remaining ports.

The present invention additionally initializes such a multiport component to a predetermined type and value or to the type and value of a saved state if one exists.

The present invention further provides the user with means to utilize such a component in an effective, non-intrusive manner.

The above objectives are achieved by utilizing an object oriented component having multiple bidirectional ports that is adapted for use with an object oriented based applet or application. The component's ports are all first initialized to a predetermined value and thereafter polled to determine if an input has been coupled to any one of the ports. If it has not, polling continues. If an input is present, all of the component's remaining ports are set to output the same type and value as that of the input. Where appropriate, a check is made to determine if a saved state of the component exists, if it does, the component is initialized to the state type and value rather than the predetermined type and value. When the input is removed, the component ports are all reinitialized to the predetermined type and value and polling for a new input commences.

The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:

FIG. 1 is a block schematic diagram of a typical computer system, for example, a personal computer system on which inventive object oriented based programming tools or development environment functions can operate in accordance with the present invention;

FIG. 2 depicts a block diagram of a Java platform development tool in accordance with a preferred embodiment;

FIG. 3 illustrates a block diagram showing the initialization process for the Visual Java Tool applet in accordance with a preferred embodiment;

FIG. 4A shows an example of an illustrative World Wide Web home page as loaded by a Java enabled browser in accordance with a preferred embodiment;

FIG. 4B illustrates the same web page with its main pull-down menu activated in accordance with a preferred embodiment;

FIG. 4C depicts the "Open File" pull-down menu of the home page shown in FIG. 4B in accordance with a preferred embodiment;

FIG. 4D shows the VJ Tool applet after it has been initialized and is ready to run in accordance with a preferred embodiment;

FIG. 5 illustrates the physical or end user view screen portion in accordance with a preferred embodiment;

FIG. 6 shows the creation of a scrollbar which will be used to indicate Centigrade temperatures in an example of how the present invention can be utilized in accordance with a preferred embodiment;

FIG. 6A is a functional block diagram depicting socialization of new components in accordance with a preferred embodiment.

FIG. 7 visually describes an example of marqueing or sizing of a vertical scrollbar in accordance with a preferred embodiment;

FIG. 8 depicts another example of marqueing or adjusting the size of a vertical scrollbar to a shorter, slightly wider, outline in accordance with a preferred embodiment;

FIG. 9 illustrates an example of a scrollbar object matching the same object in FIG. 8, but created in the logical view in accordance with a preferred embodiment;

FIG. 10 shows the two pin value setting and getting capability of the scrollbar of FIG. 8 in accordance with a preferred embodiment;

FIG. 11 illustrates the addition of a second vertical scrollbar that will be set to track the range of the Fahrenheit temperature scale in accordance with a preferred embodiment;

FIG. 11A is a flowchart of the detailed logic of the editor component in accordance with a preferred embodiment,

FIG. 12 depicts how label text is added to the scrollbars of FIG. 11 to label the scrollbar in accordance with a preferred embodiment;

FIG. 13 shows how text from a label editor has been placed as a label above the first scrollbar of FIG. 11 in accordance with a preferred embodiment;

FIG. 13A illustrates a flowchart for the process by which the bicopy component shown in FIG. 13 functions in accordance with a preferred embodiment;

FIG. 14 illustrates the addition and use of splitters in the logical view in accordnace with in accordance with a preferred embodiment;

FIG. 15 shows the addition of a calculator object to the logical view in accordance with a preferred embodiment;

FIG. 16 depicts an additional calculator and the interconnections of several objects to achieve the appropriate Centigrade/Fahrenheit relationship between scrollbars of FIG. 11 in accordance with a preferred embodiment;

FIG. 16A is a flowchart of the detailed logic for port connection in accordance with a preferred embodiment;

FIG. 17 shows the final result of the conecteded scrollbars with correct Fahrenheit and Centigrade temperatures shown in the text fields in accordance with a preferred embodiment;

FIG. 18 is a diagram in block format of an arrangement adapted to provide collaboration between components or portions of components of an applet as designated by the user in accordance with a preferred embodiment;

FIG. 19 presents a flowchart of the collaboration process in accordance with a preferred embodiment;

FIG. 20 illustrates a screen with the logical view in accordance with a preferred embodiment;

FIG. 21 illustrates a screen with the logical and physical view preparing a hierarchial component in accordance with a preferred embodiment;

FIG. 22 illustrates a screen with a connection made for playing a sound in accordance with a preferred embodiment;

FIG. 23 illustrates an edit screen for a folder component utilized to prepare a hierarchial component in accordance with a preferred embodiment;

FIG. 23A is a functional block diagram depicting editing of a folder to prepare a hierarchical component in accordance with a preferred embodiment.

FIG. 24 illustrates a hierarchial component creation customization in accordance with a preferred embodiment; and

FIG. 25 illustrates the completed physical view of a hierarchial component in accordance with a preferred embodiment.

The invention is preferably practiced in the context of a suitable operating system resident on a workstation or desktop computer, such as a SUN, IBM, PS/2, or Apple, Macintosh, computer. A representative hardware environment is depicted in FIG. 1, which illustrates a typical configuration for a computer system 100 that can be utilized to practice the subject invention. The computer 100 is controlled by a central processing unit 102 (which may be a conventional microprocessor). A number of other units, all interconnected via a system bus 108, are provided to accomplish specific tasks. Although a particular computer may only have some of the units illustrated in FIG. 1, or may have additional components not shown, most computers will include at least the units shown.

Specifically, computer system 100 shown in FIG. 1 includes a random access memory (RAM) 106 for temporary storage of information, a read only memory (ROM) 104 for permanent storage of the computer's configuration and basic operating commands and an input/output (I/O) adapter 110 for connecting peripheral devices such as a disk drive unit 113 and printer 114 to the bus 108, via cables 112 and 115, respectively. A user interface adapter 116 is also provided for connecting input devices, such as a keyboard 120, and other known interface devices including a microphone 124, a mouse 126 and a speaker 128, to the bus 108. Visual output is provided by a display device 122, such as a video monitor, which is connected via display adapter 118 to bus 108. Lastly, a communications adapter 134, connected to bus 108, provides access to a network 136.

The computer 100 has resident thereon and its basic operations are controlled and coordinated by operating system software such as the SUN Solaris, Windows/95, Windows NT or the Java OS operating system. For purposes of the preferred embodiment as described herein, regardless of the operating system being used, computer 100 is provided, at the very least, with the Java run time environment and an optional Just-In-Time (JIT) Java compiler.

In a preferred embodiment, the invention is implemented in the Java programming language, relying substantially on its object-oriented programming techniques. Java is a compiled language, that is, Java based programs are typically written in a human-readable script which script is eventually provided as input to another program called a compiler. The compiler generates a byte code version of the script that can be loaded into, and directly executed by, any computer which contains a Java virtual machine. Java objects are compiled to class files that include bytecodes representative of the original source code program with references to methods and instance variables of the Java objects. The bytecodes are not specific to particular machines or operating systems and don't have to be recompiled or rearranged to run on different hardware/software platforms. Rather, the bytecodes can be run in the Java Virtual Machine or passed to a (JIT) compiler that converts them into native code for a target platform on the fly.

This means that the original Java application or applet bytecode, which isn't specific or native to any one hardware platform or architecture, can be run without recompilation on any hardware or software platform that has a Java Run-Time Environment. In other words, a Java program's native architecture is the Java VM which is or will soon be available in both software and hardware implementations, making Java applications and applets multi-platform capable as long as the target system is Java enabled. As described below, the Java language has certain characteristics which allow a software developer to easily use and reuse programs written by himself or others while still providing a reason for reuse of programs or portions of programs to prevent their destruction or improper use.

Sun's Java language has emerged as an industry-recognized language, not only for "programming the Internet, but also as " . . . a serious programming language capable of tackling the most sophisticated business applications." Sun defines Java as: "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independentJava applets." Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g. simple animation, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g. Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically "C++, with extensions from Objective C for more dynamic method resolution".

Another technology that has function and capability similar to JAVA is provided by Microsoft and its ActiveX technology, to give developers and Web designers the wherewithal to build dynamic content for the Internet and personal computers. ActiveX runs only the so-called Wintel platform (a combination of a version of Windows and an Intel microprocessor), as contrasted with Java which is a compile once, run anywhere language.

ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over one hundred companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft's Visual C++, Borland's Delphi, Microsoft's Visual Basic programming system and, in the future, Microsoft's development tool for Java, code named "Jakarta." ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications. One of ordinary skill in the art will readily recognize that ActiveX and ActiveX components could be substituted for JAVA and its components as their use is described herein without undue experimentation to practice the invention.

Further explanation of the Java programming language, its characteristics and advantages is not deemed necessary. Java is now well-known and many articles and texts are available which describe the language in great detail. In addition, compilers and development kits are commercially available from several vendors including SunSoft Inc., Borland International, Inc. and Microsoft Corporation. Accordingly, for reasons of brevity and clarity, additional details of the Java language and the operation of the Run-Time Environment or the JIT compilers will not be discussed further in herein since this information can be readily obtained elsewhere. One appropriate source can be found in Gosling, Joy & Steele, The Java Language Specification (1996), the disclosure of which is hereby incorporated by reference. Another source for Java VM information is Sun Microsystems' Java Virtual Machine Specification, Release 1.0 Beta DRAFT (Aug. 21, 1995), the disclosure of which is also hereby incorporated by reference.

The arrangement described above concerning the running of Java applets and applications is illustrated in FIG. 2. This block diagram shows how a Java application or applet can be run on one or more hardware/software platform combinations. The applets can be obtained, along with the static information (text and/or graphics) of the web page they are resident on, by either an ordinary web browser or one that is Java enabled. If the applet is obtained by a non-Java enabled browser, as depicted in block 202, it is passed via connection 203 to the Java Run-Time Environment 206 where the applet code is compiled into Java bytecode class files. The bytecode is then checked for security purposes by the bytecode verifier and then run on the Java VM by the bytecode interpreter to yield Java derived code that can be input to the optional JIT compiler 208 via connection 207 for conversion to platform native code.

Java source is compiled into bytecodes in an intermediate form instead of machine code (like C, C++, Fortran, etc.) to enable and facilitate portability. The bytecodes execute on any machine with a bytecode interpreter. Thus, Java applets and applications can and do run on a variety of client machines. Further, since the bytecodes are compact and designed to transmit efficiently over a network, Java enhances a preferred embodiment with universal clients and server-centric policies.

The output of the JIT compiler 208 is passed therefrom via connection 209 to a target platform 210. Target platform 210 could be, for example, a Windows combination, a Macintosh System 7/PowerPC combination or a Unix/RISC combination. If the Operating System (OS) of the target platform is Java enabled, that is, if it includes its own Java Run-Time environment, then the Environment 206 output could be passed directly via connector 211 to the target platform 210 avoiding the Java JIT compiler 208 whose services would not be needed.

Alternatively, if an applet is obtained by a Java enabled browser (such as Sun's HotJava, Netscape's Navigator 3.0 or Microsoft's Internet Explorer 3.0) which includes and has already installed the Java Run-Time Environment on the computer where it resides, there is no need to utilize the separate Environment 206. Applets so captured are passed via connector 213 through by the Java enabled browser at 212 to the Java Environment, also logically part of block 212, where such applets are handled as described above in connection with function block 206. Lastly, stand-alone Java applications are passed directly to the Java Environment block 206 where they are handled and processed in a similar manner to the Java applets. The Java applications do not need to be obtained nor do they work in conjunction with a browser. However, if a Java enabled browser is loaded on the developer's hardware, as is probable, a Java application can be passed directly to the browser of function block 212 via connector 215 and handled in the same manner as an applet would have been.

A preferred embodiment of an applet that will be known as the Visual Java Tool (or VJ Tool hereafter) takes the concept of objects and applies it through the entire development system to provide a development or authoring tool that is robust, easy to use and one that minimizes the amount of code a developer needs to write. VJ Tool is described herein in the context of an applet, but as it has been noted, VJ Tool could also be provided as a full application and handled in the manner described above. The user of VJ Tool would not have to be knowledgeable about Java or OOP and could build or create a Java applet or application from scratch just by using VJ Tool in the manner described herein.

FIG. 3 is a block diagram that shows the initialization process for the Visual Java Tool applet in accordance with a preferred embodiment of the invention. The applet 302 is seen by a Java enabled browser 304, such as Sun's HotJava or Netscape's Navigator, via link 305 and then downloaded via connection 303 to the client computer on which the browser resides. Alternatively, the VJ Tool can be obtained from local storage as an application. When browser 304 is activated, it also initializes and makes the Java Run-Time Environment 306 active thereby initiating and readying the Java Virtual Machine for the eventual arrival of an applet.

Once obtained from its web page or local storage, the VJ Tool is itself initialized as shown in block 308 and made ready for interaction with a user, see block 310. Initialization of the applet includes initialization of the desktop (VJContainer) and the web page view (VJDocument). VJContainer and VJDesktop are tightly coupled. VJContainer is a container API. The details of applet initialization for VJ Tool are included in VJContainer and VJDesktop.

For each component, a template is initially used to define the particular characteristics of the component. The template includes a start, stop, initialize, destroy, connect, disconnect, customize (edit), save, load and one or more component specific task methods. These methods are customizable for each of the components so that the sliderbar component has a different disconnect method then a button component. ##SPC1##

The source code enabling the container editor for modifying properties of the container is presented below. When a new component is instantiated on either the physical or logical display, an optional customizer (edit) window is presented if a containerEditor method is defined for the component. The customizer (edit) window is defined in the template as a method corresponding to the customizer (edit) method. The method contains the logic facilitating the dynamic definition of properties of the component and the update of the properties based on user interaction with the customizer (edit) window. ##SPC2##

VJ Tool dispatches start stop and init messages to all active instances of components as start(), stop() and init(). When VJ is loading, we want to have the user wait until that process is completed, so VJ Tool will ignore events and a splash sheet with a warning message is displayed that says no action will be possible until loading is completed. Once VJ Tool is loaded and initialized completely, the warning screen is dropped and user interaction is enabled.

The initialization process initializes and enables the logical view and the physical view. The initialization processing includes VJ Tool's data structures and palettes, which comprise "primitive" or basic building block components coded entirely in Java. Once initialization is completed, the cut, paste, select all, move, drag, drop, point, and other functions are active. These functions associated with the VJ Tool menu bars are defaulted from the VJContainer class. The palettes and menus are created from VJDesktop.

VJ Tool then invokes user requests and such actions as may be appropriate thereto, as indicated in block 312. Once all requests have been satisfied, VJ Tool cycles back through link 314 and waits for subsequent user requests. If there are no further requests to be carried out, the user exits via block 316.

FIG. 4A shows an example of a World Wide Web home page that is displayed when the Netscape Navigator is invoked in accordance with a preferred embodiment. If this page had included a Java enabled applet, that applet would have been downloaded and activated as soon as the user clicked on it. Alternatively, an applet could be locally resident and thus be directly available. FIG. 4B illustrates the same web page with its main pull-down menu activated. FIG. 4C depicts the "Open File" pull-down menu of the home page shown in FIG. 4B. Note that the files found in the local file "saul.htm" include the applet called "DemoRelease", which is actually a back level version of VJ Tool, ready to select and run.

FIG. 4D shows the VJ Tool applet after it has been initialized and is ready to run. VJ Tool comes up on the user's screen after being initialized and deployed with two main views as shown in FIG. 4D. These views are equivalent to the status depicted by block 310 in FIG. 3. Window 402 shows the active VJ Tool desktop, in particular, its logical view 402. Logical view 402, also called the document view, is created from VJDocument. Window segment 404 is the right hand portion of the base home page shown in FIGS. 4A, 4B and 4C. The other view, the user physical view is shown in FIG. 5. ##SPC3##

The palette in logical view 402, as shown in FIG. 5, is provided with a series of components that are instantiated from the component VJContainer. FIG. 5 illustrates the physical view or end user view screen portion in accordance with a preferred embodiment of the VJ Tool.

FIG. 5 also shows the physical view 500 of the VJ desktop. The logical view 402 is in the foreground on the right hand side of the drawing, while the physical view 500 is in the background on the left side of the screen. Physical view 500 is provided with palette containers 502 to 530 as follows: 502 is a select cursor button; 504 is a simple AWT label; 506 is a simple AWT text field; 508 is a simple AWT text area; 510 is a simple AWT button; 512 is a simple AWT checkbox; 514 is a simple AWT choice box; 516 is a simple AWT list; 518 is a simple AWT horizontal scroll bar; 520 is a simple AWT vertical scroll bar; 522 is a simple bar chart; 524 is a simple spreadsheet; 526 is a simple AWT panel; 528 is a calendar; and 530 is an animator.

Logical view 402 is provided with palette containers 540 to 572 as follows: 540 is a select cursor button; 542 is a VJ folder or container; 544 is an adder; 546 is a bicopy component. The bicopy component acts as a multiplexor so that whatever is input on one pin of a bicopy element is output on its other pins. 548 is a test for equals; 550 is a constant (e.g. -1 or 3.1457 or "abc"); 552 is a random number generator; 554 is a counter; 556 is an URL opener; 558 is a splitter used to connect input/output pins to components that are either input or output elements; 560 is a two-dimensional grapher; 562 is a three-dimensional grapher; 564 is a delta three-dimensional grapher; 566 is an URL text viewer; 570 forwards input from any one of an element's input pins to an outpin pin thereof; 572 is a calculator; and 574 is a sound player. AWT is the Abstract Windowing Toolkit and contains the objects utilized for providing basic windowing functions in accordance with a preferred embodiment.

The components of logical view 402 and physical view 500 can be dropped, respectively, from their palettes into the view they are associated with. Moving the cursor over any component causes a short description of that component to appear in the logical view.

FIGS. 6 through 17 illustrate an example of a VJ Tool used to quickly, efficiently and accurately create an applet derived mini application that does not require the VJ Tool user to write a single line of code. Unlike other "visual" tools currently available, VJ Tool is a "point and click" and "drag and drop" development environment in which the components are all activate immediately. It is important to note that VJ Tool provides a "live" environment; that is, you can see modifications you make take hold or be applied as the component is utilized. The physical view results in corresponding changes in the logical view. If you eliminate a component from the physical view, it disappears as well from the logical page and if you change the properties of a component in the physical view, its associated component in the logical view reflects that change as it is made. The components initialization method occurs when the component is instantiated and the component immediately communicates with the other components previously defined for the physical and logical display.

The component's "liveness" refers to immediate activation of components as components are interactively added to the environment. The action of the components is analogous to a What You See Is What You Get (WYSIWIG) word processing environment in which immediate feedback of status and value information is available. So, for example, as a button is placed on the display, it is immediately available for connection to a player component to display text or activate a multimedia presentation.

"Liveness" and "live", as used in this description, are terms employed to illustrate how the present invention promotes and permits immediate socialization of new components, as they are instantiated or dropped into either the logical or physical views, with existing components. This is achieved, as depicted in the functional block diagram of FIG. 6A, by registering the component being instantiated with the VJ Kernel via block 620. Registration, in turn, invokes an initialization method in block 622 that appropriately personalizes the new component when it executes the logic associated with the initialization method, see block 624, which can include the provision of an editor for the new component if its properties are to editable. The new component can immediately communicate or socialize with other components previously defined in the logical and physical views as shown by block 626.

Liveness also indicates that the environment is tested as new components are instantiated. This means that immediate connections between components are permitted on the fly. There is no requirement that all possible connections are tried first to insure that nothing blows up. The outcome of this capability is that design creation and trial are integrated so that the results can be observed virtually at the same time that the interconnection of components is made. As noted later herein in connection with the description of FIG. 16, this is analogous to building a hardware prototype or test board by interconnecting, disconnecting and moving electronic components around the test board while the power is left on. As will be shown by the following example of Fahrenheit and Centigrade conversion, there is immediate feedback of component status and value information. This makes VJ Tool, in essence, a WYSIWIG development environment.

The specific example shown in various stages in FIGS. 6 through 14 depicts two scroll bars that have been adapted through use of VJ Tool to display conversions of Fahrenheit and Centigrade temperatures to each other on a dynamic basis. This applet has been created in the physical view and reflected in the logical view in accordance with a preferred embodiment of the present invention.

FIG. 6 shows the creation of a first scroll slider bar 602 which will be used to indicate Centigrade temperatures. This object has been instantiated by clicking on the vertical scroll bar component 520 and then dragging and dropping the object to its FIG. 6 position in the physical view 500. When scroll bar 602 is created, its editor, vertical scroll bar editor 604, pops up as a dialog box wherein the current, visible, maximum and minimum values of the scroll bar just crated are displayed and can be edited. As shown, scroll bar 602 has a current value of fifty, it is showing only ten units of its total range which varies from a maximum of one hundred (boiling point) to a minimum of zero (freezing point).

FIG. 7 is an example of marqueing or sizing the vertical scrollbar in accordance with a preferred embodiment. This is done by using the mouse to drag the edges or handles 606, see FIG. 6, of scroll bar 604 until the desired scroll bar shape is achieved. The result of that action is shown in FIG. 7 where the original scroll bar has been lengthened and reduced in width to form scroll bar 604a. FIG. 8 illustrates another example of adjusting the size of the vertical scrollbar 604a to a shorter, slightly wider, outline 604b. The logical view 402 can be seen in FIG. 8, where it remains in the background, available for use as may be needed.

The source code for the VJScrollbar component is presented below.

FIG. 9 depicts an example of a VJScrollbar object 604b in the logical view 500. The physical view 402 illustrates a simple AWT horizontal scrollbar 902 having diamond shaped I/O pins or ports 904. The diamond shape indicates that the I/O pin is bi-directional or two way in operational nature; that is, they accept inputs or transmit outputs, as they are utilized. The I/O pins can be shaped like a triangle, rather than a diamond. If they are diamond shaped, then those I/O pins will handle an output or an input depending on the direction in which they point. I/O pins 904, which are sometimes referred to as "net pins", can be coded as follows:

FIG. 10 shows the two pin capability of scrollbar 604b. Note that each of the pins 902 and 904 are diamond shaped or two way ports. If a value if placed on these ports, it sets the scrollbar to that level. Conversely, if a value is taken from one of these ports, it reflects the position of scrollbar 604b.

In practice, the two way or bidirectional ports are first initialized to their two way state. The ports can then function either as an input port or as an output port depending solely on the way they are used. Each bidirectional port is provided with bidirectional capability by having a send message method defined for all outgoing transactions and a receive message method defined for all incoming transactions in the component for each bidirectional port. Thus, the method corresponding to the direction is invoked based on the flow of the message through the port.

For example, if inputs are connected to the two-way ports 904a or 904b in FIG. 10, they would function as input ports. Two-way port 906 would then function as the output port since it is the only port left that could serve in that role. In the preferred arrangement, components set themselves internally to reflect the status of each of their bidirectional ports, in accordance with the way they are being used. The bidirectional ports permit greater connective flexibility and save screen real estate as well.

When a connection to another component is completed, the connecting component sends a message to the component at the other end of the connection indicating how its connecting port is set, input or output. The message receiving component then makes sure that its connection participating port is set accordingly. If the message receiving component's port is bidirectional, the port is set opposite to the status of the first connected port. If the message receiving component's connecting port is bidirectional, that port is set opposite to the status of the first connected port. If the message receiving component's port is unidirectional and as such is in conflict with the status of the first connected port, that is, it is set to "output" when the first connected port is also set to "output", the connection is prohibited and an appropriate error message is displayed.

FIG. 11 illustrates the addition of a second vertical scrollbar that will be set to track the range of the Fahrenheit temperature scale. Note that the vertical scrollbar editor 1104 has been adjusted to set scrollbar 1102 to a maximum value of 212 (boiling point) and a minimum value of 32 (freezing point). Prior to being adjusted, scrollbar 1102 has a current value of 71 with only 10 units of its total range actually visible.

Dynamic editing is accomplished by providing each component that would have need of an editor with that capability as an integral part of the class template from which it is instantiated. Each customizer window or editor is defined in predetermined class templates as a method corresponding to the customizer method.

Thus, when such edit capable components are instantiated in either the logical view 402 or the physical view 500, their built-in customizer or edit widow 1104 is invoked, see FIG. 11, and opens automatically. The editor appears in the view ready for use to change or customize the properties of the component, in this case scrollbar 604b, based on user interaction with the customizer or editing window 1104.

As shown in the flowchart of FIG. 11A, editor capability is added at block 1120 to each class template for which an editing capability is desired in component objects instantiated therefrom. An editing window, as indicated by block 1122 is defined as a method corresponding to the editor. The properties and their limits are also defined for each component editor as shown by block 1124. An editing window is opened by block 1126 when the component with which it is associated is dragged and dropped or instantiated for use.

After the user finishes editing the component's properties and clicks "OK", the editing window is closed and the property changes are accepted and displayed immediately in the appropriate view by block 1128. After property editing is completed, the editable components are monitored for a user action (usually a mouse click) which indicates that property re-editing is desired for a specific component, as per block 1130. When that occurs, block 1132 opens the editor widow 1104 again to permit component property changes to be made. Thereafter, control is returned to block 1128 and the user re-editing changes are accepted. Finally, monitoring of the editable components resumes as per block 1130.

It is important to note that the user is not required to take any action to invoke an editor or be concerned about the suitability or appropriateness of the editor with respect to the component being customized. Moreover, the editor is customized for the specific component with which it is associated. If an editor appears when a component is instantiated, then the user instantaneously knows that that particular component is customizable. In addition, the user sees and knows just which properties of the component are editable and to what limits. Further, the user can make any desired customizing changes without having to write any code to implement those changes. Other uses of a component editor are shown in FIGS. 12 and 15.

FIG. 12 shows how VJ Tool is utilized to add text to scrollbars 604b and 1102 so that the function they perform or represent can be labeled and thereby identified to any user. First, the simple text field component 506 is invoked by clicking on its icon and dragging it onto the physical view 500. The text field representation 1202 can then be dropped at any desired location and, as desired, sized to match the element it will identify, in this case scrollbar 604b. The text field or label editor 1204 is then used to generate the actual text or scrollbar label.

The label text field component is coded as follows:

As shown in FIG. 13, text field 1202 has been made into the "CENTIGRADE" label 1202a above scrollbar 604b through use of the text field editor 1204. Label "FAHRENHEIT" 1302 has been generated in the same manner and positioned above scrollbar 1102 (not shown in FIG. 13).

It should be noted that several of the components described herein, vertical scrollbars 604a and 604b and text field 1202 label editor, are provided with their own editors, vertical scrollbar editor 604 and label editor 1204, which permits the predefined properties of the associated components to be directly and dynamically edited. Such editing takes place without the user having to exit VJ Tool or having to write any code to support the desired editorial changes.

FIG. 13 also illustrates in logical view 402, representations of scrollbars, text and bicopy objects that will be used to functionally link scrollbars 604b and 1102. Objects 1306 and 1312 logically represent scroll bars 604b and 1102 while label objects 1304 and 1310 represent the labels 1202a and 1302 respectively. Bicopy is a backend component that is only found in the logical view palette. A bicopy object, such as 1308 and 1314, as implemented in accordance with a preferred embodiment of the present invention, will place whatever is input on one of its diamond shaped I/O pins 1308a, 1308b, 1308c or 1398d on the other I/O pins.

Bicopy, which functions like a multiplexor, is coded as follows:

FIG. 13A illustrates a flowchart of the process by which the bicopy component 1308 shown in FIG. 13 functions. The act of dragging and dropping a new bicopy component onto the logical desktop 402 or of dropping an assembly from folder 542, which assembly contains a bicopy component, onto the logical view desktop 402 actually starts the bicopy component as called for in block 1330. A test is next made to see there is a saved, prior state for bicopy element 1308 that needs to be restored by decsion block 1332. If restoration is neded, control is passed to block 1334 which obtains the necessary values and has the ports set accordingly in block 1344.

If the bicopy component is new, its two-way ports are initialized or set to zero in bock 1336. Once that has been done, the ports are polled in block 1338 to monitor connection attempts. Decision block 1340 returns control to block 1338 for continued polling if there were no connections made to any of bicopy's component ports. If a proper connection has been made, a connection sufficient to place a value on one of the bicopy componet's ports, control is passed to block 1342 where the type and value of the connection is identified.

Thus, if a connection has been made from a text field, a character string is placed on one of the bicopy component's ports and captured by the Bicopy component. Similarly, if an integer value, such as 32, isplaced placed on one of the bicopy component's ports, that type and value is also recognized and captured. Once the type and value of an input are known, the remaining ports are set to provide the same type and value as the input by block 1344. Thus, at this point, see FIG. 16, bicopy component 1308 would have its port 1308c set by the output of scrollbar representation 1306 to the current value (position) of the scrollbar. This means that ports 1308a, 1308b and 1308d, which act as output ports, will carry the output value of scrollbar 1306 until the input connection to port 1308c is changed.

Decision block 1346, which is advised of the initial connection by block 1342, checks for removal of the input value to bicopy component 1308 and returns control back to block 1344 if it has not been removed or to block 1336 for reinitialization if it has been removed.

FIG. 14 shows addition of splitters 1402 and 1404 in the logical view 402. Splitter objects 1402 and 1404 are used to connect I/O pins to components that are functionally involved in a defined relationship appearing in the logical view 402. Splitters are instantiated form the splitter palette component 558 of logical view 402 and are dragged and dropped to a suitable location on the logical view desktop. Splitter objects are formed pursuant to their implementing code (VJSplit) as follows:

FIG. 15 shows the addition of a calculator object 1502. Calculator object 1502 is instantiated from calculator component 572 of the logical view palette when the mouse is clicked over the calculator icon and the resulting image is dragged into the logical view window. When calculator object 1502 is created, evaluator editor 1504 is popped up so that expressions to be evaluated by the calculator can be input thereto. In this particular example, the Fahrenheit to Centigrade conversion expression to be evaluated is entered and the calculator is thereby informed what its computational task will be.

FIG. 16 illustrates the interconnections of several objects to achieve the appropriate Centigrade/Fahrenheit relationship between scroll bars 604b and 1102. Building on to the arrangement depicted in FIG. 15, the user would add two simple text field objects 1602 and 1603 in physical view 500 by clicking on the simple text field icon 506 twice and then dragging and dropping each resultant text field object 1602 and 1603 so that each is located below and adjacent to the scrollbar it contains information for.

When the text field objects are created, logical representations thereof, 1604 and 1606 respectively, are created by VJ Tool in the logical window. The appropriate interconnections between and amongst the several objects in the logical view 402 are then made and the results displayed in the text fields 1602 and 1604 as a direct function of where the scrollbars are actually located. Since scrollbar 604b is at its minimum position, which is zero, text field 1602 accurately displays that result. The display of the position results in a text field without the intervening need to write additional code to transform the scrollbar output, an integer or floating point value to an ASCII string. VJ Tool takes care of that task for the user and permits concentration on the problem being solved.

VJTextField is coded as follows:

In this example, interconnections are made by mouse click, drag and drop operations as follows. The output of scrollbars 1306 and 1308 are connected to the bicopy objects 1308 and 1314 respectively. That value is passed from bicopy object 1308 to splitter 1402 and text field representation 1604 and from bicopy object 1314 to splitter 1404 and text field representation 1606. In addition, the output of splitter 1402 is coupled to the input of calculator 1502a while the output of splitter 1404 is coupled to the input of calculator 1502b. Finally, the outputs of calculators 1502a and 1502b are respectively connected to the inputs of splitters 1402 and 1404. Thus, when scrollbar 604b is moved to a new position, the value of that position is transmitted by the scrollbar object 1306 to bicopy object 1308 and from there to text field component representation 1604. This means that the text fields 1602 and 1603 both display the changing values for their associated scrollbars 604b and 1102 when either one of them is moved to a new position.

It is rather important to note that the interconnections described above between objects on the logical view are subject to type and functionality checking in a dynamic manner when they are attempted. Thus, the connection in FIG. 16 that was made between the output port of splitter 1402 and the input port of calculator 1502a is functionally permissible and was permitted to be made in a manner that was transparent to the user. Conversely, if an attempt had been made to connect the output port of splitter 1402 to the output port of calculator 1502a, that attempt would have been denied as functionally impermissible. In a similar manner, had an attempt been made to the output of calculator 1502a to the input of text label object 1304, that connection would have been denied since the input type (a value or number) was mistyped as an input to text label object 1304 which only accepts input of type char or a string of characters. This functional and type compatibility checking is performed by the VJDesktop code as set forth above.

The port or netpin type verification works in the following functional manner. When a component or object pin is created by being dropped onto the logical view desktop 402, its presence there and the number and nature of its pins, if any, is logged, stored and tracked by the VJDesktop code. Specifically, the number and types of ports or netpins on the newly instantiated component or object is noted Once a component or object having pins is instantiated, VJDesktop tracks and stores the status of its ports by polling them periodically as depicted by block 1620 in FIG. 16A. The same is true for variables, the information for which is initially stored when a component that can pass, duplicate or manipulate a variable is instantiated.

As used herein, the term "initiate a connection" means that the mouse has been clicked over only one port in preparation for tacking the line that appears to another port. Once that other port is clicked on, the connection is deemed to be completed.

Decision block 1622 is advised by block 1620 whether or not a connection to one of the ports has been initiated. If no attempt to initiate a connection has been made, polling continues. If a connection has been initiated, the type of port involved (input, output or bidirectional) and, if known, the type of variable expected (character, float, long integer, short integer, string, etc.) on that port are stored as per block 1624 with VJDesktop and control waits for completion of a connection for the involved port while polling continues for the remaining ports.

Decision block 1626 sends control back to polling if the pending connection has not yet been made. If the connection is completed, control for the ports involved is passed to decision block 1628 which decides if the attempted complete connection between the ports involved is valid. The type of ports involved and their functional affinity for each other will be checked and verified. Connections directly between an input port on one component will not be allowed to an input port on another component nor will a direct connection between an output port on a first container to an output port on a second container. Also forbidden are connections between ports on the same component regardless of their type.

In addition to checking that interport connections are valid, decision block 1628 also ascertains if the variable to be transmitted across the new connection is valid for both ports. By referring to the stored component and object port information, it can be determined, for example, that the variable at the output of calculator 1502a in FIG. 16 is mistyped as to the variable expected at the input of label 1304, a character or string. As a result, when that otherwise valid output to input connection is attempted, it would be prevented by decision block 1628 because of a variable type mismatch.

When the attempted connection is invalid, an error message will be sent to the screen for the user to see and notification is sent to block 1620 to keep on polling for completion of the initiated, but not completed connection. If the attempted connection is valid, it is completed and also reflected on the display and the polling block 1620 is so advised. The stored port information is updated and the system waits for the next attempted connection. If a completed connection is ended, decision block 1634 is so advised by polling block 1620 and the stored type information for that connection is appropriately adjusted to reflect that the ports which were involved in the ended connection are now free for other use.

FIG. 17 shows the final result of the coupled scrollbars with correct Fahrenheit and Centigrade temperatures shown in text fields 1602 and 1603, respectively. With both scrollbars at their minimum positions, the Centigrade scrollbar 604b position produces the value 0 in text field 1602. In similar fashion, scrollbar 1102 produces a value of 32 in text field 1603. If scrollbar 604b is pulled down to position 1702 where it has a value of 80, as will then be displayed in text field 1602, then scrollbar 1102, because of what are essentially feedback connections made in FIG. 16, will move to position 1704 which will cause text field 1603 to then display its corresponding value of 176 degrees. Because of the cross coupling described in connection with FIG. 16, moving scrollbar 1102 first to a position of 176 would cause scrollbar 604b to be positioned at the point that represents the value 80, which would be displayed in text field 1602.

As described above, the VJ Tool provides a live development or authoring environment in which socialization among objects or components can occur immediately upon their creation or instantation without any wait to plan or test their integration. For example, as shown in FIG. 16, once the output of bicopy object 1308 was connected to text field representation 1604, the output value of scrollbar 1306 was displayed in the physical view 500. If this result is not what was desired, the user can change the connection or add another component on the fly without having to debug code or review a flowchart. Similarly, when the output of splitter 1404 is connected to the input of calculator 1502b and displayed via text field representation 1606, the user is able to make an immediate determination that the conversion calculations are correct and that the displayed arrangement is satisfactory. In other words, being able to make connections on the fly immediately proved or disproved the results obtained because VJ Tool creates a "live" environment wherein applet design creation and trial are integrated so that the result is then played out virtually simultaneously with creation. This is analogous to building a hardware prototype or test board by connecting, disconnecting and moving components around the board while the power is on|

Component 542 of FIG. 5 is a folder component in which associated components can be stored to act as templates for other applets to be designed in the future. Say, for example, that a user had designed the specific arrangement shown in FIG. 16 and dragged it as a component assembly into an object folder instantiated from folder 542. That object folder can later be opened and the component assembly stored therein be reused or its calculators modified to display Centigrade versus Kelvin or with slightly more modification to the text and label fields, feet versus meters. In fact, a hierarchy of folders can be built up in this manner. Unlike ordinary folders which are static and store only files that can be copied in an ordinary fashion, component folder 542 actually stores parts or all of a program with its interconnections intact.

To build a hierachial component, a component is instantiated on a logical or physical display. Then, a hierarchial component folder is selected and instantiated on the display. The customization (edit) window is completed to reflect an appropriate name for the particular component folder and the customization window is closed. Another window is presented for receipt of one or more components and their connections to capture and create the "hierarchial component." Thus, the hierarchial component acts as an organizer to capture debugged logic and make it available to other applets without modification.

There are several kinds of components in VJ Tool. For example, as shown in FIG. 5, there is a GUI primitive such as 508, a primitive spreadsheet 524, a primitive backend component 570 (calculator) and a backend component 558 (splitter). In addition, some of the components have the ability to be made collaborative, that is, they can interact with each other to show or indicate interdependencies. For example, if three users are working with collaborative spreadsheets, a change made by one user will also be reflected in the spreadsheets of the other two users. This makes it easy to keep all members of a team current with respect to changes in spreadsheet information. Under VJ Tools, collaborative components work as follows.

To begin the collaboration process, a standard VJ Tool component, such as a spreadsheet 524, is created from the physical view palette of VJ Tool, see FIG. 5. As shown in FIG. 18, there would be a copy, 524a, 524b and 524c, of each spreadsheet object instantiated for each client user, 1806a, 1806b and 1806c, that wanted their spreadsheet to be collaboratively coupled to other spreadsheets. Collaboration can be extended to the entire spreadsheet or it can be limited to designated cells in the spreadsheet. For example, individual cells in each spreadsheet can be collaborated by simply clicking on them or the entire spreadsheet can be collaboratively coupled by simultaneously pressing the <CONTROL> key while clicking on any portion of the spreadsheet. It is also possible to have two collaborating spreadsheets completely linked to each other while one of these is linked to a third spreadsheet on a designated cell basis only.

All such standard components to be collaborated are augmented with code than connects them to a VJ Spreadsheet Server, a Java application, that is running on the same HTTP server as the VJ Tool applet. VJ Spreadsheet Server is responsible for managing the collaboration. This arrangement is necessitated by the fact that this is the only way a Java applet, when VJ Tool is implemented as a Java applet, can interact with a Java server application through a designated socket.

The clients, 1808a, 1808b and 1808c, are typically connected across the Internet 1810 to an HTTP server 1802. The HTTP server 1802 can include many applications and applets and it often does, but for the sake of clarity there are only three applications, 1804a, 1804b and 1804c, and three applets, 1806a, 1806b and 1806c, shown. Application 1804c, designated for purposes of this explanation as the Java Server, is usually a daemon server, has full access to the underlying file system and can be used to communicate with related servers, not necessarily Java servers, on the Internet.

In the simplest mode, collaborative capable components, are associated with one or more Java servers running on the same HTTP server that houses and services the VJ Tool applet. As each instance of such components are created and deployed in the VJ Tool environment, and collaboration is desired, each collaborative component to be is registered with the Java server, in this case 1804c. The process of registration builds an instance 1812a of the registering component 524a in Server 1804c. It will also build a similar instance of the other components involved, 1812b and 1812c, as they are registered. Once registered with the Java Spreadsheet Server 1804c, the component, assume it's 524a for purposes of this discussion, sends out information to Server 1804c based on interactions with the user and possibly other registered components, 524b and 524c, in the deployment environment; that is; other collaborative components to which a changing component is tied. In addition, the collaborated component 524a will receive information from Server 1804c which it may choose to use as feedback to the user or to the other collaborated components with which it is so associated. Basically, the message set "Publish cell", "Unpublish cell" and "Update cell" is used to alter cell content.

However, each time the collaborative arrangement is initialized, nothing is shared between the collaborated components unless the state of the last session was saved and reloaded at initialization into Spreadsheet Server 1802. Since the registration process builds a record in Server 1804c of which portions of which collaborated components are coupled, it is relatively straightforward for the Server to accumulate this information from a changed component, which utilizes a publish message to send it there and then republish or broadcast it to the other collaborated components to effect updating, thereby making it public. Thus, nothing is seen by any of the unchanged collaborated components until the Spreadsheet Server 1802 has relayed the changed information on to them.

A flowchart of the collaboration process is illustrated in FIG. 19. When a new component is created as in block 1902, the user is asked by decision block 1904 if the new component should be collaborative. If not, the user and VJ Tool go off via block 1906 and do something else. If the user responds in the affirmative to the query of block 1904, the component properties are examined to determine if this specific component can be collaborated by decision block 1908. If collaboration isn't possible, control is passed to block 1910 which sends an appropriate message to the user and then waits for the user to make another request.

If a new component can be collaborated, it is registered with a Java server as shown in function block 1912. The server, as indicated by block 1914, then builds an instance of the registering component in order to know which components it is responsible for. In addition, pursuant to block 1916, the server builds a record listing those portions, some or all, of the registered components which are linked or collaborated. Once that identity and designated linked portions of the components have been identified and recorded, the server changes the infirmation in the collaborated portions when it receives information from a component as shown in block 1918 and broadcasts the changed information to the other collaborated components via block 1920.

Collaboration within the VJ Tool, in accordance with the foregoing description, is accomplished utilizing the source code presented below.

FIG. 20 illustrates a screen with the logical view in accordance with a preferred embodiment. A sound component 2000 has been instantiated on the logical view by dropping a sound icon onto the logical desktop 2010.

FIG. 21 illustrates a screen with the logical and physical view preparing a hierarchical component in accordance with a preferred embodiment. A button 2120 has been instantiated and customized 2110 on the logical desktop 2114 and its physical representation 2100 is also reflected in the physical desktop 2112.

FIG. 22 illustrates a screen with a connection made for playing a sound in accordance with a preferred embodiment. The button component 2200 is connected 2210 to the sound component 2220 in the logical desktop 2230. The Play Sound Button component 2240 is the physical view in the physical desktop 2250.

FIG. 23 illustrates an edit screen for a folder component utilized to prepare a hierarchical component in accordance with a preferred embodiment. A Container 1 folder 2300 is instantiated in the logical desktop 2350 by dropping a folder component 2360 on the desktop. A customize or edit window 2310 pops up when the folder is instantiated. This edit window can be utilized to change the name of the folder and the number, location and type of active ports of the folder component. The Container 1 folder is logically represented by a window 2320 where the logic of the folder (hierachial component) can be created on the fly by adding or deleting components in the window 2320. The button 2330 is also shown in the physical desktop 2340.

As shown in FIG. 23A, a folder class with options for unidirectional and bidirectional ports and an editor is first created as depicted by block 2370. The user instantiates a folder component by dragging and dropping it onto the logical desktop 2350 as reflected by block 2372.

When the folder is instantiated and its edit window 2310 pops up, as described above, the folder name and the number, location and type of ports can be selected or changed. This capability is reflected in block 2374. Finally, as shown by block 2376, the folder component waits on the user to indicate what other components, including other folders, should be placed within it. This procedure is described hereafter in connection with FIG. 24.

FIG. 24 illustrates a hierarchical component creation customization in accordance with a preferred embodiment. The button 2400 which was originally in the logical desktop 2420 has been moved into the Container 1 folder 2410. The internal connectors 2430C and 2440C are represented in the Container 1 folder 2410 and refer back to the logical desktop ports 2440L and 2430L of the folder 2450 in the logical desktop 2420. The ports can be used to transfer information into and out of a folder 2410. One of ordinary skill in the art will readily recognize that other components could be added to the Container 1 folder 2410 to create a more complex hierarchical component which could even include nested and recursive hierarchical components.

FIG. 25 illustrates the completed physical view of a hierarchical component in accordance with a preferred embodiment. The sound button 2500 in the physical view 2520 is now inside the folder 2510 which can be used to simplify complex logic on the logical desktop 2530 and reduce screen clutter. This technique can be utilized to capture debugged components and component assemblies in a single representation of many components. Users can thus create their own components.

While the invention is described in terms of preferred embodiments in a specific system environment, those skilled in the art will recognize that the invention can be practiced, with modification, in other and different hardware and software environments within the spirit and scope of the appended claims.