METHOD AND APPARATUS FOR STATIC AND DYNAMIC GENERATION OF INFORMATION ON A USER INTERFACE
Related Applications The following identified U.S. provisional patent application is relied upon and is incorporated in its entirety by reference in this application:
Provisional U.S. Patent Application No. 60/054,817, entitled "Method and Apparatus for Building Intranet Applications with Compiled HTML Pages Using Embedded Java," filed on August 5, 1997.
Background of The Invention Field of the Invention
This invention generally relates to user interfaces on computer based systems and more particularly, to a method and apparatus for static and dynamic generation of information on a user interface. Description of Related Art
The World Wide Web (WWW) was originally designed as a way people running different types of computers could share and view documents over the Internet. To obtain information, a user executes an application on their computer called a web browser. The user can use the web browser to request information, display information, and interact with information through graphical user interface components such as buttons, hypertext links, and sliders.
To make a request, the user sends a uniform resource locator (URL) address over the network associated with the desired information. This URL address specifies exactly where the computer is located on the WWW and where the information is stored on the computer. Typically, the information is stored in a file called a web page. Computers on the network route the URL address request to a web server process running on a server computer where the web page is located. The web server retrieves the correct web page and returns it to the user making the request.
Many of the early web pages only contained static information. The content in these static web pages was defined in advance and stored on a server computer. People creating these static web pages formatted the information in the web pages using hypertext markup language (HTML) codes. The HTML provided structure to
the text by specifying where text should be located on a page and how it should look when displayed in the web browser. The static web pages always appeared the same because the static web pages were designed in advance.
Software developers quickly created techniques to dynamically generate web pages based on information collected from the user. In a dynamically generated web page, the information contained in the web page is entered into the web page when the user makes a request for information. Instead of requesting a static web page from the server, the user sends a URL address to the server corresponding to a Common Gateway Interface (CGI) script. The web server receiving the URL then invokes the CGI script on the server to collect the requested information and create a web page dynamically. CGI scripts are often used to query databases and retrieve other selected information stored on the server computer. The web server then sends the dynamically created web page to the user's web browser.
Software developers often use several different types of scripting languages in CGI script applications. For example, one CGI script could invoke scripts written in the "Perl" programming language, the "Awk" programming language, as well as the "Tel" programming language. For information on Perl, see "Programming Perl", by Larry Wall and Randall L. Schwartz, O'Reilly & Associates, 1991, and for information on Awk see "The Awk Programming Language ", by Alfred V. Aho, Brian W. Kernighan and Peter J. Weinberger, Addison- Wesley, 1998. Because these scripting languages are interpreted, not compiled, it is easy for the software developers to rapidly prototype and develop many small applications. In some cases, CGI applications are easy to modify and manage because they use a small amount of code and perform relatively simple operations.
More companies are beginning to use web browsers and web servers to create complex enterprise systems. As these web applications become more complex, the CGI scripts are increasingly difficult to modify and manage. First, a software developer has to learn the syntax, semantics, and operational characteristics of numerous different scripting languages to develop a powerful CGI script. The software developer may also need to learn how to connect each of the scripting languages with special application programming interfaces used for databases and
other online services. Because several scripting languages are used together, the web developer must also learn how to use several different debuggers for each of the different scripting languages.
Complex CGI scripts can also be very slow when they are executed. Each scripting language loads a special interpreter into memory before the script can be executed. If a CGI script uses multiple scripting languages, the user requesting information may experience a significant delay while different interpreters are loaded into memory. Also, these interpreters often occupy a significant amount of memory and may deplete the memory capacity of a server when many requests are made in a short time period.
Developing complex web applications with CGI scripts is also difficult because the web server executing on the server is stateless. Stateless means that the web server does not retain the state of a request or transaction once the transaction has been completed. Some web applications overcome this limitation by storing state information in a "cookie" and storing the cookie on the client computer. The cookie is a small file created by the web server which may include information on the user and the state of one or more previous transactions. Unfortunately, many people do not accept cookies on their computer because they fear the possibility of infecting their computers with viruses.
It is desirable to develop a programming language useful in generating web pages containing dynamic and static information. The programming language should be stateful and keep track of a user's information as they interact with the information. Use of cookies or other devices to keep state information should not required. It is also important that this programming language is relatively easy to use and backward compatible with existing web browsers and other GUI applications.
Summary of The Invention
In accordance with the present invention, a user can request a web page with static information and dynamic information by invoking a presentation object located on a server. The presentation object is created by compiling object-oriented code together with structured text, such as text formatted using HTML. The structured text can be used to display static information on the web page. People can modify the
structured text portion of the presentation object without modifying the object- oriented programming language. More sophisticated software developers can use the object-oriented programming language to generate information to be used in the web page. By combining object-oriented code and structured text, users can develop complex web pages for use in enterprise networks.
In accordance with the present invention, as embodied and broadly described herein, a user creates an object-text source file that integrates structured text and object- oriented code. This object-text source file may also include structured text fields that indicate where dynamic information should be placed. A compiler designed in accordance with the present invention converts the structured text and object-oriented code into an integrated object-oriented code module. The compiler also compiles the integrated object-oriented code module into a presentation object.
Another aspect of the present invention relates to invoking the presentation object and generating static and dynamic information for display in a user interface such as a web browser. Initially, a server executing on a server computer receives a request for information. The server parses a presentation object name from the request and creates an instance of a presentation object corresponding to the presentation object name. The presentation object was created from a combination of structured text and object-oriented code. Next, the server invokes a method associated with the presentation object that generates structured text having static text and dynamically generated text. For example, the structured text can be displayed on a web browser compatible with HTML codes. The server then transmits the structured text generated by the method to a web browser application to be displayed.
Brief Description of The Drawings The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, serve to explain the principles of the invention. In the drawings:
FIG. 1 is block diagram of an exemplary system in which methods and systems consistent with the present invention may be implemented;
FIG. 2 is a flow chart for generating presentation objects using a compiler designed in accordance with the present invention;
FIG. 3 is a flow chart indicating the method steps used to generate an object-text source file;
FIG. 4 is a flowchart of the steps associated with converting an object-text source file into an integrated object-oriented code module; and
FIG. 5 is a flowchart diagram indicating the steps associated with invocating a presentation object using a presentation manager.
Detailed Description Introduction
Reference will now be made in detail to an implementation of the present invention as illustrated in the accompanying drawings. The same reference numbers will be used throughout the drawings and the following description to refer to the same or like parts.
Methods and systems consistent with the present invention provide a user with the ability to request a web page by invoking a presentation object located on a server. This web page can contain both static information and dynamic information. Static information is stored in the web page before a user makes a request while dynamic information is generated when the user makes the request. The presentation object is created by compiling object-oriented code together with structured text, such as text formatted using HTML. The structured text can be used to display static information on the web page. People can modify the structured text portion of the presentation object without modifying the object-oriented programming language. More sophisticated software developers can use the object-oriented programming language to generate
information to be used in the web page. As a result of combining object-oriented code and structured text, users can develop complex web pages for use in enterprise networks. System Configuration
FIG. 1 is block diagram of an exemplary system 100 with which methods and systems consistent with the present invention may be implemented. System 100 includes a client computer 103, a server computer 101, and a network 108 coupled to the client computer 103 and server computer 101. Client computer 103 includes a World Wide Web (WWW) browser 105 capable of displaying web pages described in text markup language such as HTML. Web pages generated using implementations of the presentation invention are transmitted to WWW browser 105 from server computer 101.
Server computer 101 includes a memory 102, a CPU 104, a network interface 106 coupled to a network 108, and a bus 114 which provides connectivity and communication among these subsystems. Bus 114 can communicate using a standard bus protocol such as Industry Standard Architecture (ISA), Peripheral Component Interconnect (PCI), or Small Computer System Interface (SCSI). Network 108 may be a Local Area Network (LAN), a Wide Area Network (WAN), or the Internet.
Memory 102 includes object-text source 121, an object-text compiler 122, a presentation object 124, a presentation manager 126, application objects 128, a World Wide Web (WWW) server 130, and a runtime system 132, such as the Java™ runtime environment. These elements are used together in one implementation of the present invention to display information on a user interface executing on the client's computer. For example, a software developer can use these elements to develop web pages for display on a client computer using a web browser application.
Object-text source 121 includes structured text 116, text fields 118, and object- oriented code 120. Object-text source 121 encapsulates these different elements into a single file that a text editor can modify. Special tags are used to delimit structured text 116, text fields 118, and object-oriented code 120. These elements in object-text source 121 can be easily modified by software developers. This makes it easy to edit one portion of object-text source 121 without affecting other portions of the application.
Structured text 116 can be any block of text formatted with a markup language such as HTML. The structure in the text is used to format the text and other information
for printing on a printing device (not shown) or display on display device 112. HTML (hypertext markup language) is one markup language widely used on the WWW because it is relatively easy to use and popular with many users. In alternative implementations, other markup languages such as Standard Generalized Markup Language (SGML) or Extensible Markup Language (XML) can also be used for structured text 116. Information on SGML can be found in "The SGML Handbook", by Charles F. Goldfarb, Oxford University Press, 1990 which is incorporated herein by reference and information on XML can be found in "XML: Principles, Tools, and Techniques", World Wide Web Journal, Volume 2, Issue 4, Fall 1997 O'Reilly & Associates, Inc., pages xii - 248 which is also herein incorporated by reference. Typically, structured text 116 represents the static portion of information sent to a client requesting data from a server. For example, structured text 116 could include a standard copyright notice sent to all users requesting a web page from a server.
Text fields 118 are used to indicate where dynamic portions of text should be placed. A user creates text field 118 by surrounding a string, such as the string "Lastname," with delimiters as follows: (@Lastname@). When a web page having this text field is requested, an object-oriented instruction generates the user's last name and inserts this information into the web page. A user inserts text field 118 within the structured text 116 to combine static text with dynamically generated text. This customizes the presentation of information to the user. For example, a text field such as (@Lastname@) placed in structured text 116 portion of object-text source 121 displays the user's lastname when a web page designed in accordance with the present invention is requested.
A user develops object-oriented code 120 to assist in processing a request. Object-oriented code 120 invokes objects that modify text fields 118. For example, object-oriented code 120 can be used to insert text and corresponding tags in a cache object when a user requests information. The cache object is an object for storing and retrieving frequently used information. A tag value is used to retrieve information in the cache object quickly. Accordingly, object-oriented code 120 invokes a method that inserts text entries in the cache object as indicated by text fields 118. Later, these text entries are retrieved from the cache and used to create a web page. In one
implementation, a cache object can be developed in the Java programming language by extending a hash.table object provided in the Java programming language Development Kit.
Object-text compiler 122 converts structured text 116, text fields 118, and object- oriented code 120 into an integrated object-oriented code module. For example, object- text compiler 122 can be used to convert HTML structured text intermixed with text fields 118 and Java™ programming language instructions into a single application written completely in the Java™ programming language. The resulting integrated object- oriented code module can then be compiled using a traditional object-oriented compiler, such as a Java™ programming language compiler, into an object-oriented executable or class file. Applications developed using implementations of the present invention can then be ported quickly to any computer system compatible with the object-oriented language.
Presentation object 124 includes methods and routines to generate a static and dynamic information in response to a user's request and for display on a user interface such as a web browser. Presentation object 124 can be created by compiling the object- oriented code generated by object-text compiler 122 into an object or class. In operation, presentation object 124 resides on a server computer and responds to requests for information from a user on a client system. When the user on the client system makes a request, methods within presentation object 124 generate static and dynamic information in response to the request. These methods display this information in a user interface on a user's display device. For example, presentation object 124 can generate static HTML combined with dynamic HTML generated when object-oriented methods are executed. The dynamic HTML may contain personal information associated with the user or information specific to the user's request such as a stock quote. Both the static HTML and dynamic HTML can be displayed on a web browser capable of displaying HTML structured text.
Presentation manager 126 receives a request for a presentation object and invokes the appropriate presentation object to fulfill the request. Multiple presentation objects 124 may exist on a server to fulfill different requests and generate different types of information for display on a user interface. Presentation manager 126 processes the
requests to deteπnine which presentation object 124 to invoke. For example, a user may request information using a URL and include several parameters. Presentation manager 126 processes the URL to determine which presentation object to invoke, where the presentation object is located, and also determines how to pass the parameters to the presentation object.
Application objects 128 implement the core logic of an application not directly related to the presentation of information. Because presentation object 124 is separate from application objects 128, a user can modify application objects 128 without affecting the operation of presentation object 124.
Core logic in application objects 128 may include any preliminary tasks to be performed before information is presented on a user interface to the user. For example, these preliminary tasks can include invoking data objects that gather data from different databases or invoking computation objects that perform calculations on the information gathered from the database. Application objects 128 can invoke processes located on different computers or may invoke processes on a single computer.
WWW server 130 is a process executing on server computer 101 which processes requests from clients for information and sends results back to the requesting client. Generally, the results are contained in structured text, such as HTML, that the user can display on a web browser. The user can request WWW server 130 to retrieve static information on the server or execute an application designed in accordance with the present invention to generate dynamic and static information.
Initially, the user sends the location of the static information or application in a URL. A suffix on the URL indicates to WWW server 130 what type of application has been requested or what type of static information has been requested. For example, a URL "http://www.nowhere.com/AcmeAppSuite/loginSplash.po" having a ".po" suffix indicates to WWW server 130 that a presentation object "loginSplash.po" implemented consistent with the present invention is located on the WWW at "www.nowhere.com/AcmeAppSuite/". To execute this presentation object, WWW server 130 invokes presentation manager 126 to create an object-oriented context the presentation object can execute in. This context includes objects having parameters and
data the presentation object may use for processing. Once the context is created, presentation manager invokes presentation object 124.
Runtime environment 132 provides an execution environment that enables system 100 to allocate system resources and process applications. Runtime environment 132 includes a virtual machine, such as the Java™ Virtual Machine, an operating system, and an Application Programming Interface (API), such as the Java™ API, that allows applications to access runtime environment 132 and other subsystems in system 100. A virtual machine, such as the Java™ Virtual Machine, is an abstract computing machine that executes on a processor such as CPU 104 and interprets bytecode instructions. A virtual machine can be a process in memory 102 simulating execution of the abstract computing machine instructions or it can be a CPU 104 with an instruction set compatible with the particular abstract computing machine architecture. The Java™ Virtual Machine, and the Java™ API are provided as part of the Java™ Development Kit (JDK) from Sun Microsystems, Inc. of Mountain View, California. Exemplary Generation of Presentation Objects
FIG. 2 is a flow chart for generating presentation objects using a compiler designed in accordance with the present invention. Compiling presentation object 124 creates a class with a predetermined entry method executed when the presentation object is initially invoked. Presentation object 124 generates static information intermixed with information generated dynamically on the user interface of a user's computer. For example, the predetermined entry method in presentation object 124 is invoked by calling the method labeled "run()". The run() method contains object-oriented code that intermixes static information with dynamically generated information.
Initially, the user creates object-text source file 121 that integrates structured text 116, text fields 118, and object-oriented code 120 (step 202). These elements in object- text source file 121 can be created using a text editor. Object-text compiler 122 parses the object-text source file into structured text 116, text fields 118, and object-oriented code 120 so each section can be processed separately (step 204). Object-text compiler 122 converts structured text 116, text fields 118, and object-oriented code 120 into an integrated object-oriented code module (step 206). This conversion step converts non- object-oriented code, such as structured text fields and structured text, into equivalent
object-oriented instructions. Next, object-text compiler 122 compiles the integrated object-oriented code module into presentation object 124 having a predetermined entry method (step 208).
Referring to FIG. 3 is a flow chart indicating the method steps used to generate an object-text source file. The flow chart in FIG. 3 corresponds to step 202 in FIG. 2. Initially, the user generates a structured text module containing static text information (step 302). This static text information in the structured text module represents the portion of a user interface which is not created dynamically for the user. For example, this static text information may be a block of HTML code used to display a "Welcome" banner for a user logging onto an application. Tags in the HTML language well known in the art are used to format the static text for display on the web browser running on the user's computer. For information on the HTML language see "HTML : The Definitive Guide", by Chuck Musciano, Bill Kennedy, published in 1997 by O'Reilly & Associates and incorporated herein by reference. An example of static structured text using HTML is provided in Table 1 :
<HTML>
<HEAD>
<TITLE> Acme Application Suite: Logon Successful</TITLE> <HTTP-META="Refresh" CONTENT=2; URL=/AcmeAppSuite/mainMenu> </HEAD> <BODY>
<Hl>Logon Successful </Hl> Welcome to the Acme Application Suite <P> Please be patient while your profile is retrieved... </BODY> </HTML>
Table 1 : Structured Text Module Containing Static Text Information
To generate information dynamically within the static text in Table 1 , the user inserts text fields 118 within structured text 116 using a text editor (step 304). Text field 118 contains a string with delimiters around the string indicating where the dynamic information should be located. In one implementation of the present invention, the text field is replaced with object-oriented instructions when the object-text source file is compiled into a presentation object. These object-oriented instructions generate information dynamically when presentation object 124 is invoked.
For example, assume a user creates a presentation object based on the object- oriented code in Table 2. To generate information dynamically, the user enters text field (@cgi.id@) as shown on line 9 in Table 2. This text field is replaced with an object- oriented instruction that retrieves a text value from a cache object corresponding to the tag "cgi.id". The cache object is a temporary storage area used to store information based on a tag value. At runtime, this object oriented instruction uses the "cgi.id" tag to retrieve information from the cache object and generate information on a web page dynamically.
1. <HTML>
<HEAD>
<TITLE> Acme Application Suite: Logon Successful</TITLE> <HTTP-META="Refresh" CONTENT=2; URL=/AcmeAppSuite/mainMenu> </HEAD> <BODY>
<Hl>Logon Successful </Hl> (@cgi.id@) Welcome to the Acme Application Suite <P> Please be patient while your profile is retrieved... </BODY> </HTML>
Table 2: Structured Text Module Containing Structured Text Fields and Static Text Information
The user can also develop object-oriented code that invokes objects and modifies information referenced by text fields 118 (step 306). This allows the user to perform more sophisticated data processing and display a wider variety of dynamically generated information. For example, object-oriented code can be used to manipulate and extract information from databases, perform statistical calculations on information, or generally customize data used by the presentation object. The code in Table 3 provides an object- text file having object-oriented code in lines 6 to 17, structured field text at line 29, and static structured text in lines 19 to 32 The object-oriented code begins after the delimiter "<JAVADEF>" and ends just before the delimiter "</JAVADEF>".
Implementations of the present invention also provide a method for importing application objects and object-oriented code into the presentation object. This is useful for reusing objects and methods. In this example, the user imports "acme.appsuite.businessObjects.*" on line 3 in Table 3. More application objects could be included by listing them after the "<JAVAIMPORT>" start delimiter and before the "</JAVAIMPORT>" end delimiter.
<JAVAIMPORT>
// Import all the application objects, including the session manager/presentation (what is this?) manager?? import acme.appsuite.businessObjects.* ; </JAVAIMPORT> <JAVADEF> private void getName (JoltPage page) {
String id = page.data.get("cgi.id"); try {
// The following will throw a noSession exception if the id is // not known. Catch this and set the presentation field to // "Unknown User". page.data.set ("name", acme.appSuite.sessionMgr.getUserName(id)); } catch (NosessionException e) {
// Make sure the name is set to some value page.data.set ("name", "unknown user"); } }
<JAVADEF> <HTML>
<HEAD>
<TITLE> Acme Application Suite: Logon
SuccessfuK/TITLE> <HTTP-META="Refresh" CONTENTS; URL=/AcmeAppSuite/mainMenu> </HEAD>
<JAVACALL METHOD=getName></JAVACALL> <BODY>
<Hl>Logon Successful </Hl> (@name@) Welcome to the Acme Application Suite <P> Please be patient while your profile is retrieved... </BODY> </HTML>
Table 3: Structured Text Module Containing Object-oriented code along with
Structured Fields and Static Structured Text Information
(Line numbering added for reference purposes only and holding added for emphasis)
When the code in Table 3 is compiled and invoked, the static text on lines 19 through 25 is displayed on a user interface. At line 26, the object-oriented method getName( ) at line 6 is called. The getName method assumes that a user identification number has been provided by the user and stored in a cache object called page.data. In the Java programming language, page.data can be defined as an extension of the hash.table object. Further, getName assumes a list of user names and corresponding identification numbers have been registered in the system. In this example, at line 7 the getName method defined in the presentation object obtains the user identification number "cgi.id" from the page.data object and stores it in an "id" variable. A sessionMgr object at line 11 in Table 3 calls a getUserName method that converts the user identification number ("id") into a string value corresponding to the user's name. Also on line 11, the page.data object calls a "set" method to store the string value and corresponding "name" tag in the page.data object. If the user identification number is not registered in the system, the "name" value in the page.data object is set on line 15 to a default value "Unknown User". Now, when lines 27 through 31 are displayed at execution time, structured field text "(@name@)" either displays the user's name or displays "Unknown user."
FIG. 4 is a flowchart of the steps associated with converting an object-text source file 121 into an integrated object-oriented code module. A compiler performing this conversion step substitutes static structured text with object-oriented code and creates an integrated object-oriented code module suitable for compilation and execution.
Initially, the compiler generates object-oriented instructions that correspond to structured text 116 located in object-text source 121. HTML type structured text begins after an <HTML> delimiter and ends before an </HTML> delimiter in object-text source 121. The compiler uses such delimiters to determine if structured text exists in the object-text source file (step 402). If structured text exists, the compiler generates object- oriented instructions capable of displaying text strings corresponding to the structured text (step 404). These instructions are inserted into a predetermined entry method in the object-oriented code module. The predetermined entry method is called the run() method and it is invoked when the presentation object is invoked.
The compiler also generates object-oriented instructions that correspond to the structured text fields located in the object-text source file. A structured text field tag begins after a "(@" delimiter and ends before the "@)" delimiter. For example, (@name@) could be one structured text field having the tag "name". The compiler uses these delimiter pairs to determine if structured text fields exists in the object-text source file (step 406). If a structured text field exists, the compiler generates an object-oriented instruction to read a structured text field values from a cache object based upon the specified tag (step 408). These instructions are also inserted into the predetermined entry method in the object-oriented code module. In one implementation, the compiler might replace a (@name@) structured text field with an object-oriented instruction: page.data.get(String "name"). This would cause the object-oriented program to get the string value corresponding to the tag "name" from the page.data cache object at run time.
The compiler also determines when object-oriented code exists in the object-text source file. Object-oriented code begins after a "<JAVADEF>" delimiter and ends before the "</JAVADEF>" delimiter. The compiler uses this pair of delimiters to determine if object-oriented code exists in the object-text source file (step 410). If object-oriented code exists, the compiler copies the object-oriented code into the predetermined entry method in the object-oriented code module (step 412).
The compiler continues to process the object-text source file in sequence until no more sections of text or code exist. If more delimited sections exist in the text file, the compiler will continue to process each delimited section in the order received (step 418). This ensures the static and dynamic text are generated in the correct sequence when the presentation object is eventually invoked. Alternatively, if no more delimited sections exist in the file, then the conversion process is complete (step 420). Exemplary Invocation of Presentation Objects Using a Presentation Manager
FIG. 5 is a flowchart diagram indicating the steps associated with invoking a presentation object using a presentation manager. The presentation manager provides parameters and other information to the presentation object in an object-oriented context. By doing this, non-object-oriented applications can interact with the presentation objects. For example, a web server executing on a server can invoke a presentation object by sending the URL directly to the presentation manager. The presentation manager invokes
the presentation object and returns the results back to the web server for further processing.
In operation, a client transmits a request for information using an application such as a web browser (step 502). On the Internet or an intranet, a web server executing on a server system receives this request in the form of a URL such as http://www.nowhere.com/ AcmeAppsuite/loginSplash.po?id=l 7264. The web server detects this URL corresponds to a presentation object designed in accordance with the presentation invention and passes the request to a presentation manager. The presentation manager can execute on the same computer as the web server or can execute on a different computer on the network. In one embodiment, the ".po" suffix indicates the request is for a presentation object and not a CGI script or static HTML web page.
The presentation manager parses the request in the URL into connection information (step 504). This connection information can include location of the presentation object, the name of the presentation object, and any parameters the presentation object may need during execution. The presentation manager extracts the presentation object name from the connection information and saves the remaining connection information for later use (step 506). Once the presentation object is located on the server or the network, it is loaded into memory and prepared for use (step 508). If the presentation object is developed using the Java programming language, a class file corresponding to the presentation object may be loaded into memory at this point. Time spent loading this presentation object or class may be reduced if the presentation manager determines the presentation object or class is already in memory and can be reused.
The presentation manager then creates a presentation object (step 510). In accordance with one implementation of the present invention, the presentation manager instantiates a presentation object corresponding to the presentation object name. This presentation object is unique in that it was created from a combination of structured text and object-oriented code. The presentation manager then loads the remaining connection information in the presentation object (step 512). This connection information may include the parameters and data the presentation object needs the process the request. The presentation manager creates a presentation communication (PC) object to hold
information that the presentation object uses to process a request. The PC object is also used to hold results the presentation object has generated.
The request information stored in the PC object includes the type of content being transmitted, the length of data being transmitted, and the actual stream of data. For example, a user can send a request which includes a 3 megabyte file encoded as a Portable Document Format (PDF) file. The PC object would contain methods for determining that the data type is a PDF file and that the PDF file is 3 megabytes in size. The actual PDF file would be accessed using an input stream referenced in the PC object. Once the connection information is loaded into the PC object, the presentation manager calls the predetermined entry method in the presentation object to generate static structured text and text generated dynamically (step 514). Depending on how the application is developed, different methods within the presentation object may selectively copy portions of data in the PC object into a local cache such as a page.data object. Local cache is an area that an application uses to store frequently used information. Applications can also retrieve information quickly from the local cache area.
The presentation object can invoke numerous objects and call numerous methods to fulfill the user's request for information. Some instructions may generate static text, such as static HTML code, and insert this information in an output stream to be sent back to the user making the request. Other object-oriented methods called by the presentation object may generate text dynamically and insert the text and tags in a local cache such as the page.data object. Meanwhile, other instructions in the presentation object may retrieve the text stored in the local cache and insert it into the output stream to be returned to the user.
In one implementation, the presentation object's response is packaged back into the PC object as a response object. The PC object used to respond includes content type and the output stream being sent back to the user making the request. The PC object may also include the quantity of the information in the PC object. The presentation manager sends structured text and dynamic text stored in the PC object back to the web server for further processing (step 516).
While specific implementations have been described herein for purposes of illustration, various modifications may be made without departing from the spirit and
scope of the invention. In one alternative implementation, implementations of the present invention can be created using non-object-oriented programming languages as well as other object-oriented programming languages other than the Java programming language. Further, although web browsers and web servers are discussed in one implementation other server applications and graphical user interface applications can also be used. Also, implementations of the present invention can be used on any network and should not be limited to the Internet, intranets, extranets, or any other networks. Those skilled in the art understand that the present invention can be implemented in a wide variety of hardware and software platforms and is not limited to the above described embodiments, but instead is defined by the appended claims in light of their full scope of equivalents.