Information Messaging and Collaboration System
An information messaging and collaboration system is described. In one embodiment, for example, a method is described for interactive content retrieval and display, the method comprises steps of: providing a plurality of portlets for retrieval of content for display in a user interface; mapping a message action to a first portlet to create a messaging portlet for sending a message in response to user interaction with the messaging portlet; creating a listener portlet by registering a second portlet to receive messages from the messaging portlet; and in response to user interaction with the messaging portlet, retrieving particular content for display in the user interface based on the message received by the listener portlet from the messaging portlet.
Latest SYBASE, INC. Patents:
CROSS REFERENCE TO RELATED APPLICATIONS
The present application is related to and claims the benefit of priority of the following commonly-owned, presently-pending provisional application(s): application Ser. No. 60/481,287 (Docket No. SYB/0094.00), filed Aug. 25, 2003, entitled “Information Messaging and Collaboration System”, of which the present application is a non-provisional application thereof. The present application is related to the following commonly-owned, presently-pending application(s): application Ser. No. 09/780,993 (Docket No. SYB/0090.03), filed Feb. 8, 2001, entitled “System and Method for Dynamic Content Retrieval”. The disclosures of each of the foregoing applications are hereby incorporated by reference in their entirety, including any appendices or attachments thereof, for all purposes.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
Computer Program Listing Appendix under Sec. 1.52(e): This application includes a transmittal under 37 C.F.R. Sec. 1.52(e) of a Computer Program Listing Appendix. The Appendix, which comprises text file(s) that are IBM-PC machine and Microsoft Windows Operating System compatible, includes the below-listed file(s). All of the material disclosed in the Computer Program Listing Appendix can be found at the U.S. Patent and Trademark Office archives and is hereby incorporated by reference into the present application.
Object Description: SourceCode.text, created: Aug. 14, 2003 8:29 am, size: 3.98 KB; Object ID: File No. 1; Object Contents: Source Code.
BACKGROUND OF INVENTION
1. Field of the Invention
The present invention relates generally to information processing environments and, more particularly, to an information messaging and collaboration system providing methodology for dynamic collection and forwarding of information among system components enabling such components to process the information, modify their contents, and take action based on the information.
2. Description of the Background Art
Computers are very powerful tools for storing and providing access to vast amounts of information. The first personal computers were largely stand-alone units with no direct connection to other computers or computer networks. Data exchanges between computers were mainly accomplished by exchanging magnetic or optical media such as floppy disks. Over time, more and more computers were connected to each other and exchanged information using Local Area Networks (“LANs”) and/or Wide Area Networks (“WANs”). Initially such connections were primarily amongst computers within the same organization via an internal network. More recently, the explosive growth of the Internet has provided access to tremendous quantities of information from a wide variety of sources.
The Internet comprises a vast number of computers and computer networks that are interconnected through communication links. The World Wide Web (WWW) portion of the Internet allows a server computer system to send graphical Web pages of information to a remote client computer system. The remote client computer system can then display the Web pages in a Web browser application (e.g., Netscape Navigator or Microsoft Internet Explorer). To view a specific Web page, a client computer system specifies the Uniform Resource Locator (“URL”) for that Web page in a request (e.g., a HyperText Transfer Protocol (“HTTP”) request). The request is forwarded to the Web server that supports that Web page. When that Web server receives the request, it sends the specified Web page to the client computer system. When the client computer system receives that Web page, it typically displays the Web page using a browser application.
Currently, Web pages are typically defined using Hyper-Text Markup Language (“HTML”). HTML provides a standard set of tags that define how a Web page is to be displayed. When a user indicates to the browser to display a Web page, the browser sends a request to the server computer system to transfer to the client computer system a HTML document that defines the Web page. When the requested HTML document is received by the client computer system, the browser displays the Web page as defined by the HTML document. The HTML document contains various tags that control the displaying of text, graphics, controls and other features. The HTML document may also contain URLs of other Web pages available on that server computer system or other server computer systems. Web pages may also be defined using other markup languages, including cHTML, XML, and XHTML.
Every day, more and more information is made available via the Internet. The challenge posed to users is how to efficiently locate, access and use information and applications that are relevant to them from amongst the huge quantities of materials that are available in a variety of different formats. For example, a user may wish to collect information from three different sources. Each of these sources may potentially maintain information in a different format. For instance, one source may be a database, a second may be a spreadsheet, and a third may be a Web page.
One mechanism for providing access to personalized information is a “portal”. Corporate portals or enterprise information portals (EIPs) have many uses and advantages, but the most common overarching task of any portal is to provide users with efficient access to personalized information and applications. For an internal network, this can mean employee information such as retirement account balances and vacation requests. It may also include sales force automation and enterprise resource planning (ERP) applications. Externally, portals can collect and make information available to third parties such as business partners and customers. Portals can be used to simplify customer support, drive e-business, and/or accelerate content distribution.
A basic portal assembles static information in a single browser page for employee or customer use. Typically, static content is retrieved and placed into a giant repository which maintains all of the information used in the portal. The information is then reformatted and published to users of the portal. However managing a huge repository of content presents a number of difficulties to the organization operating the portal. One problem is that some types of information must be constantly updated. For example, stock prices or weather reports change regularly and frequently. Another problem is operating the portal and managing the associated data typically requires a skilled technical team.
To make portals more effective, organizations need to make their portals dynamic and flexible. A dynamic portal pulls updated information from company databases and other sources available through the Internet. For example, when a user goes to her home page, she wants to see the most recent headlines—not yesterday's news. A flexible portal is able to update information even if its content or location changes. In addition, organizations using portals try to make them sufficiently flexible so that they can be utilized to deliver information to new devices and new audiences in new formats.
There are a number of benefits that can be realized by ensuring that a portal is dynamic and flexible. Dynamic content guarantees the site will remain fresh and relevant for employees and third parties (e.g., customers and business partners). Without updated content, audiences will likely go elsewhere for information, and a significant investment in implementing the portal will be wasted. In addition, dynamic content makes the site more useful; keeping users on top of actionable information that can help them perform various activities.
A basic portal assembles static information in a single browser page for internal (e.g., employee) or external (e.g., customer) use. In order to provide increased relevance and flexibility what is needed is a solution that will automatically identify and gather information from many different sources (e.g., databases, flat files, documents, Web pages, and the like). The solution should combine this information to create portals that are dynamic and publish this information in real time. The solution should also enable information that is collected to be forwarded to other portals which can also modify their contents in real time, take action based on the information, and process the information (e.g., on a server or inside the user's browser) before presenting the information to the user. In addition, the solution should be easy to implement and should not require significant programming expertise or a huge repository for storing information that is collected. The present invention provides a solution for these and other needs.
SUMMARY OF INVENTION
An information messaging and collaboration system is described. In one embodiment, for example, a method of the present invention is described for interactive content retrieval and display, the method comprises steps of: providing a plurality of portlets for retrieval of content for display in a user interface; mapping a message action to a first portlet to create a messaging portlet for sending a message in response to user interaction with the messaging portlet; creating a listener portlet by registering a second portlet to receive messages from the messaging portlet; and in response to user interaction with the messaging portlet, retrieving particular content for display in the user interface based on the message received by the listener portlet from the messaging portlet.
In another embodiment, for example, a system of the present invention is described for interactive content retrieval and display, the system comprises: a user interface for display of content; an actioner module for display of content in the user interface and sending a message based on user interaction with the actioner module; a registrar for receiving the message from the actioner module and routing the message to at least one listener module registered to receive the message; and at least one listener module registered for receiving the message from the registrar and retrieving content for display in the user interface based on the message sent by the actioner module.
In yet another embodiment, for example, a method of the present invention is described for collaborative retrieval and display of information in a Web page, the method comprises steps of: providing a plurality of elements for retrieval and display of information in a Web page; creating a registrar for receiving a message and routing the message to at least one listening element registered to receive the message; associating a message action with a first element for sending a message in response to user interaction with the first element; registering at least one listener element with the registrar for receiving a message sent by the first element; and in response to user interaction with the first element, displaying particular information on the Web page based on the message received by the at least one listener element from the first element.
BRIEF DESCRIPTION OF DRAWINGS
The following definitions are offered for purposes of illustration, not limitation, in order to assist with understanding the discussion that follows.
Bytecode: A virtual machine executes virtual machine low-level code instructions called bytecodes. Both the Sun Microsystems Java virtual machine and the Microsoft NET virtual machine provide a compiler to transform the respective source program (i.e., a java program or a C# program, respectively) into virtual machine bytecodes.
Document Object Model or DOM: The Document Object Model (DOM) is a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page. For further information regarding the Document Object Model, see e.g., “Document Object Model (DOM) Activity Statement” available from the World Wide Web consortium (W3C), the disclosure of which is hereby incorporated by reference. A copy of this document is available via the Internet (e.g., currently at www.w3.org/DOM).
CGI: CGI is an abbreviation of Common Gateway Interface, a specification for transferring information between a World Wide Web server and a CGI program. A CGI program is any program designed to accept and return data that conforms to the CGI specification. CGI programs are a common way for Web servers to interact dynamically with users. Many HTML pages that contain forms, for example, use a CGI program to process the form's data once it is submitted. Another increasingly common way to provide dynamic feedback to Web users is to include scripts or programs that run on the user's machine rather than the Web server. These programs may comprise Java applets, Java scripts, or ActiveX controls. These technologies are known collectively as client-side solutions, while the use of CGI is a server-side solution because the processing occurs on the Web server. For further information regarding CGI see e.g., “CGI Specification, Version 1.1” available from the National Center for Supercomputing Applications (NCSA), the disclosure of which is hereby incorporated by reference.
cHTML: Short for compact HTML, cHTML is a subset of HTML for small information devices, such as smart phones and PDAs. cHTML is essentially a pared down version of regular HTML. Because small devices such as cellular phones have hardware restrictions such as small memory, low power CPUs, limited or no storage capabilities, small mono-color display screens, single-character font and restricted input methods (the absence of a keyboard or a mouse), cHTML provides a simpler form of HTML for use with such devices.
HTML: HTML stands for HyperText Markup Language, the authoring language used to create documents on the World Wide Web. HTML defines the structure and layout of a Web document by using a variety of tags and attributes. For further description of HTML, see e.g., “HTML 4.01 Specification”, a World Wide Web consortium recommendation dated Dec. 24, 1999, the disclosure of which is hereby incorporated by reference. A copy of this specification is available via the Internet (e.g., currently at www.w3.org/TR/REC-html40).
HTTP: HTTP is the acronym for HyperText Transfer Protocol, which is the underlying communication protocol used by the World Wide Web on the Internet. HTTP defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. For example, when a user enters a URL in his or her browser, this actually sends an HTTP command to the Web server directing it to fetch and transmit the requested Web page. Further description of HTTP is available in “RFC 2616: Hypertext Transfer Protocol—HTTP/1.1,” the disclosure of which is hereby incorporated by reference. RFC 2616 is available from the World Wide Web Consortium (W3C), and is available via the Internet (e.g., currently at www.w3.org/Protocols/). Additional description of HTTP is available in the technical and trade literature, see e.g., Stallings, W., “The Backbone of the Web,” BYTE, October 1996, the disclosure of which is hereby incorporated by reference.
Java: Java is a general purpose programming language developed by Sun Microsystems. Java is an object-oriented language similar to C++, but simplified to eliminate language features that cause common programming errors. Java source code files (files with a .java extension) are compiled into a format called bytecode (files with a class extension), which can then be executed by a Java interpreter. Compiled Java code can run on most computers because Java interpreters and runtime environments, known as Java virtual machines (VMs), exist for most operating systems, including UNIX, the Macintosh OS, and Windows. Bytecode can also be converted directly into machine language instructions by a just-in-time (JIT) compiler. Further description of the Java Language environment can be found in the technical, trade, and patent literature; see e.g., Gosling, J. et al., “The Java Language Environment: A White Paper,” Sun Microsystems Computer Company, October 1995, the disclosure of which is hereby incorporated by reference. For additional information on the Java programming language (e.g., version 2), see e.g., “Java 2 SDK, Standard Edition Documentation, version 1.4.2,” from Sun Microsystems, the disclosure of which is hereby incorporated by reference. A copy of this documentation is available via the Internet (e.g., currently at java.sun.com/j2se/1.4.2/docs/index.html).
Network: A network is a group of two or more systems linked together. There are many types of computer networks, including local area networks (LANs), virtual private networks (VPNs), metropolitan area networks (MANs), campus area networks (CANs), and wide area networks (WANs) including the Internet. As used herein, the term “network” refers broadly to any group of two or more computer systems or devices that are linked together from time to time (or permanently).
Portal: A portal provides an individualized or personalized view of multiple resources (e.g., Web sites) and services. A portal typically offers a single access point (e.g., browser page) providing access to a range of information and applications. A portal assembles information from a number of different sources (e.g., Web sites and applications) enabling a user to quickly receive information without having to navigate to a number of different Web sites. A portal also typically enables a user to obtain a personalized view of information and applications by organizing and grouping information and services for presentation to users. A portal may be considered to be composed of one or more portlets as defined below.
Portlet: A portlet is an object that is responsible for capturing and delivering information to a portal from a specific source. One or more individual portlets may then be organized on a Web page to create a portal for viewing by users using a browser. Information that may be captured by a portlet may include a Web page or portion of a Web page (e.g., collected from the World Wide Web), data retrieved from a database, flat files (e.g., spreadsheet data and documents), and/or information collected from custom interfaces to applications (e.g., information collected from an application via a Common Gateway Interface). For further information regarding portlets and portals, see e.g., “JSR168: Portlet Specification”, the disclosure of which is hereby incorporated by reference. A copy of this specification is available via the Internet (e.g., currently at www.jcp.org).
TCP: TCP stands for Transmission Control Protocol. TCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and also guarantees that packets will be delivered in the same order in which they were sent. For an introduction to TCP, see e.g., “RFC 793: Transmission Control Program DARPA Internet Program Protocol Specification”, the disclosure of which is hereby incorporated by reference. A copy of RFC 793 is available via the Internet (e.g., currently at www.ietf.org/rfc/rfc793.txt).
TCP/IP: TCP/IP stands for Transmission Control Protocol/Internet Protocol, the suite of communications protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP and IP. TCP/IP is built into the UNIX operating system and is used by the Internet, making it the de facto standard for transmitting data over networks. For an introduction to TCP/IP, see e.g., “RFC 1180: A TCP/IP Tutorial”, the disclosure of which is hereby incorporated by reference. A copy of RFC 1180 is available via the Internet (e.g., currently at www.ietf.org/rfc/rfc1180.txt).
URL: URL is an abbreviation of Uniform Resource Locator, the global address of documents and other resources on the World Wide Web. The first part of the address indicates what protocol to use, and the second part specifies the IP address or the domain name where the resource is located.
XHTML: Short for Extensible Hypertext Markup Language, a hybrid between HTML and XML. XHTML is a family of current and future document types and modules that reproduce, subset, and extend HTML 4. XHTML family document types are XML based, and ultimately are designed to work in conjunction with XML-based user agents.
XML: Short for Extensible Markup Language, a specification developed by the W3C. XML is a pared-down version of SGML, designed especially for Web documents. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations. For further description of XML, see, e.g., Extensible Markup Language (XML) 1.0 specification which is available from the World Wide Web Consortium (www.w3.org), the disclosure of which is hereby incorporated by reference. The specification is also available on the Internet (e.g., currently at www.w3.org/TR/REC-xml).
Referring to the figures, exemplary embodiments of the invention will now be described. The following description will focus on the presently preferred embodiment of the present invention, which is implemented in desktop and/or server software (e.g., driver, application, or the like) operating in an Internet-connected environment running under an operating system, such as the Microsoft Windows operating system. The present invention, however, is not limited to any one particular application or any particular environment. Instead, those skilled in the art will find that the system and methods of the present invention may be advantageously embodied on a variety of different platforms, including Macintosh, Linux, Solaris, UNIX, FreeBSD, and the like. Therefore, the description of the exemplary embodiments that follows is for purposes of illustration and not limitation. The exemplary embodiments are primarily described with reference to block diagrams or flowcharts. As to the flowcharts, each block within the flowcharts represents both a method step and an apparatus element for performing the method step. Depending upon the implementation, the corresponding apparatus element may be configured in hardware, software, firmware or combinations thereof.
Basic System Hardware (e.g., for Desktop and Server Computers)
The present invention may be implemented on a conventional or general-purpose computer system, such as an IBM-compatible personal computer (PC), a laptop computer, a notebook computer, a handheld or pocket computer, and/or a server computer.
CPU 101 comprises a processor of the Intel Pentium family of microprocessors. However, any other suitable processor may be utilized for implementing the present invention. The CPU 101 communicates with other components of the system via a bi-directional system bus (including any necessary input/output (I/O) controller circuitry and other “glue” logic). The bus, which includes address lines for addressing system memory, provides data transfer between and among the various components. Description of Pentium-class microprocessors and their instruction set, bus architecture, and control lines is available from Intel Corporation of Santa Clara, Calif. Random-access memory 102 serves as the working memory for the CPU 101. In a typical configuration, RAM of sixty-four megabytes or more is employed. More or less memory may be used without departing from the scope of the present invention. The read-only memory (ROM) 103 contains the basic input/output system code (BIOS)—a set of low-level routines in the ROM that application programs and the operating systems can use to interact with the hardware, including reading characters from the keyboard, outputting characters to printers, and so forth.
Mass storage devices 115, 116 provide persistent storage on fixed and removable media, such as magnetic, optical or magnetic-optical storage systems, flash memory, or any other available mass storage technology. The mass storage may be shared on a network, or it may be a dedicated mass storage. As shown in
In basic operation, program logic (including that which implements methodology of the present invention described below) is loaded from the removable storage 115 or fixed storage 116 into the main (RAM) memory 102, for execution by the CPU 101. During operation of the program logic, the system 100 accepts user input from a keyboard 106 and pointing device 108, as well as speech-based input from a voice recognition system (not shown). The keyboard 106 permits selection of application programs, entry of keyboard-based input or data, and selection and manipulation of individual data objects displayed on the screen or display device 105. Likewise, the pointing device 108, such as a mouse, track ball, pen device, or the like, permits selection and manipulation of objects on the display device. In this manner, these input devices support manual user input for any process running on the system.
The computer system 100 displays text and/or graphic images and other data on the display device 105. The video adapter 104, which is interposed between the display 105 and the system's bus, drives the display device 105. The video adapter 104, which includes video memory accessible to the CPU 101, provides circuitry that converts pixel data stored in the video memory to a raster signal suitable for use by a cathode ray tube (CRT) raster or liquid crystal display (LCD) monitor. A hard copy of the displayed information, or other information within the system 100, may be obtained from the printer 107, or other output device. Printer 107 may include, for instance, an HP Laserjet printer (available from Hewlett Packard of Palo Alto, Calif.), for creating hard copy images of output of the system.
The system itself communicates with other devices (e.g., other computers) via the network interface card (NIC) 111 connected to a network (e.g., Ethernet network, Bluetooth wireless network, or the like), and/or modem 112 (e.g., 56K baud, ISDN, DSL, or cable modem), examples of which are available from 3Com of Santa Clara, Calif. The system 100 may also communicate with local occasionally-connected devices (e.g., serial cable-linked devices) via the communication (COMM) interface 110, which may include a RS-232 serial port, a Universal Serial Bus (USB) interface, or the like. Devices that will be commonly connected locally to the interface 110 include laptop computers, handheld organizers, digital cameras, and the like.
IBM-compatible personal computers, laptop computers, notebook computers, handheld computers, and server computers are available from a variety of vendors. Representative vendors include Dell Computers of Round Rock, Tex., Hewlett-Packard of Palo Alto, Calif., and IBM of Armonk, N.Y. Other suitable computers include Apple-compatible computers (e.g., Macintosh), which are available from Apple Computer of Cupertino, Calif., and Sun Solaris workstations, which are available from Sun Microsystems of Mountain View, Calif.
Basic System Software
Software system 200 includes a graphical user interface (GUI) 215, for receiving user commands and data in a graphical (e.g., “point-and-click”) fashion. These inputs, in turn, may be acted upon by the system 100 in accordance with instructions from operating system 210, and/or client application module(s) 201. The GUI 215 also serves to display the results of operation from the OS 210 and application(s) 201, whereupon the user may supply additional inputs or terminate the session. Typically, the OS 210 operates in conjunction with device drivers 220 (e.g., “Winsock” driver—Windows' implementation of a TCP/IP stack) and the system BIOS microcode 230 (i.e., ROM-based microcode), particularly when interfacing with peripheral devices. OS 210 can be provided by a conventional operating system, such as Microsoft Windows 9×, Microsoft Windows NT, Microsoft Windows 2000, or Microsoft Windows XP, all available from Microsoft Corporation of Redmond, Wash. Alternatively, OS 210 can also be an alternative operating system, such as the previously mentioned operating systems.
The above-described computer hardware and software are presented for purposes of illustrating the basic underlying desktop and server computer components that may be employed for implementing the present invention. For purposes of discussion, the following description will present examples in which it will be assumed that there exists a “server” (e.g., Web server) that communicates with one or more “clients” (e.g., desktop computers, laptop computers, notebook computers, handheld computers, “smart phones”, personal digital assistants (PDAs), and/or other computing devices). The following discussion also uses examples of Web pages implemented using HTML; however, the present invention may also be used in conjunction with Web pages written in various other markup languages, including, but not limited to, cHTML, XML, and XHTML. The present invention, however, is not limited to any particular environment or device configuration. In particular, a client/server distinction is not necessary to the invention, but is used to provide a framework for discussion. Instead, the present invention may be implemented in any type of system architecture or processing environment capable of supporting the methodologies of the present invention presented in detail below.
A basic portal assembles static information in a single browser page (e.g., for use by employees or customers of an organization). To make portals more effective, organizations need to make their portals dynamic and flexible so that they are capable of collecting information from a variety of sources and updating the information even if its content or location changes from time to time. Dynamic content ensures that the site using the portal will remain fresh and relevant for employees and customers. Without updated content, audiences will go elsewhere for information, and the investment in the portal may be wasted. In addition, dynamic content makes the site more useful, keeping users on top of actionable information.
In discussing the use of dynamic content, one may think of a portal as comprised of individual “portlets”, each of which in responsible for capturing and delivering information to the portal (e.g., a Web page) from a specific source. Examples of portlets include:
Static & dynamic HTML—a Web page or portion of a Web page collected from the World Wide Web.
Database content—data retrieved from a database.
Flat File—spreadsheet data and documents (e.g., Adobe PDF files).
Custom Interfaces to Legacy Web Applications—information collected from any accessible API (e.g., a Common Gateway Interface).
Individual portlets may then be laid out on a Web page to create a portal. Thus, the task of building and maintaining a portal is, in many ways, essentially the task of building and maintaining individual portlets and coordinating their display.
The present invention introduces the concept of a “messaging portlet” or “mPortlet” for collecting and combining information from a number of different sources in a manner which provides real-time, interactive (i.e., user driven) content aggregation. A “messaging portlet” or “mPortlet” can be defined as a portlet that participates in sharing information between itself and other messaging portlets (mPortlets). Distinct and independent portlets have no knowledge of each other, their parameter requirements, and their subsequent actions. Messaging portlets are designed to be “autonomous” from other messaging portlets, from the hosting application server, and from the container in which they are enclosed. A messaging portlet can be viewed as an object with well defined messages that are “broadcast” to other mPortlet (and mContainer) objects that are “listening” for specific message content. Using well-defined message definitions, the mPortlets are “reusable” objects that can participate intelligently in combination with other mPortlets to form more dynamic and flexible portals and to establish a new form of Web application.
Information from many different sources can be used to create a messaging portlet (mPortlet). A messaging portlet can also be combined with other mPortlets to create an integrated Web based application. In addition, a “messaging container” or “mContainer” can be built based on several mPortlets. The use of messaging portlets created in accordance with the present invention provides a new type of Web application or service that can provide users with a powerful mechanism for developing new business process and analysis techniques. One advantage of this architecture is that a messaging container including several mPortlets can be deployed on any “common” Web server, and be viewed from any common browser. No operating system or browser specific code is required for implementation of these mContainers. Messaging containers can also be used within any existing content management system. These features make it easy for users to adopt, deploy, and utilize this technology.
It should be noted that there are a number of other widely used terms that are generally related to (but should be distinguished from) the messaging portlet concept. The terms “cooperative portlets” or “collaborative portlets” have been used to describe related (but different) concepts. The use of the term “collaborative portlets”, in particular, has been associated with the ability to include user or group collaboration-type functions in a portal. This definition is somewhat confusing since it crosses the definition of a portlet that includes user or group collaborative functions with a portlet that can “communicate” with other portlets. The definition and implementation of the messaging portlets (mPortlets) of the present invention as described in this document is not limited to portlets that provide user or group collaboration-type functions, but rather extends as well to other types of portlets providing other functions.
The present invention combines the use of messaging portlets with an innovative user interface that makes the solution easy to implement and use. A user without extensive technical skills or training can use the solution for identifying, extracting, and retrieving information in a number of situations that previously required complex development tasks. The system and methodology of the present invention for information messaging and collaboration will now be described in more detail.
Example of Operations
Creation of Messaging Portlets
The process of creating a calendar messaging portlet (e.g., mPortlet 320) from the standard portlet of
As the appointment anchors are mapped, “action icons” 321-325 are added after each of the five appointment anchors 311-315 as shown at
Mapping is performed in a similar manner to that used for HTML forms.
In a situation in which a given messaging portlet captures the result of a Common Gateway Interface (CGI) post, the actual CGI parameters can be replaced with information received from other mPortlets. For example,
The user can then send the form's information to the host using the Submit Query button 341 or select the action icon 343 to send the information to the map mPortlet 350 which is waiting for the information necessary to complete a CGI POST to a MapQuest host application. The address information sent to the map mPortlet 350 causes a map centered on the company address to be displayed to the user in a browser interface.
Methods of Interacting with Messaging Portlet
In the currently preferred embodiment, there are several different ways a user can interact with portlets and messaging portlets (mPortlets), including the following:
Click-Thru: Click-Thru refers to the act of refreshing the same portlet with the action of a link or a HTML form in that portlet. This is commonly used in a portlet containing Java Server Page (JSP) elements. Portlets containing JSP elements generally contain actions that change the display dependent on user data entry. This is also sometimes referred to as “Inline click-thru”.
Click-Out: Click-Out refers to the action of opening a new browser window that contains the action of a link or a HTML form in the original portlet. This is commonly used by portlets containing Web elements to provide for the whole page of the link's action to be displayed in a new browser window.
Click-Across: Click-Across is a new term introduced by the implementation of messaging portlets (mPortlets) referring to the act of refreshing a related portlet's or mPortlet's window content based on the original mPortlet's action or contents. This is an important feature of a messaging portlet and may be used in conjunction with mPortlets containing all types of elements (e.g., Java server pages, Web, HTML, Java, XML, XHTML, cHTML, Web services, etc.).
In the example shown at
Building Web Applications Using mPortlets and mContainers
The basic building blocks for powerful Web applications that use the messaging portlets of the present invention as the smallest element are referred to herein as “messaging containers” or “mContainers”. As previously described, a “messaging container” or “mContainer” is an object that contains one or more messaging portlets (mPortlets). The messaging containers (mContainers) can be used in several different ways. Messaging containers can be executed on a server to combine several processes to produce a portlet view that will be displayed on the client. Messaging containers can also be used to communicate with other mContainers in the same manner that mPortlets communicate with each other. In addition, mContainers can be used within other content management systems to provide mPortlet functionality in systems designed for static HTML portlets. Off-screen mContainers can be scheduled (e.g., using an “agent” or manager component) to collect content and cache the new mPortlet in the Web application's “ready cache” for quick rendering. A messaging container located on a server can be called from a messaging portlet so that aggregation of data is performed on the server and the aggregated results returned to the requesting mPortlet. In addition, a Web application can be built using several mContainers, each sending messages to other mContainers. Significantly, complex programming is not required in order to use mPortlets and mContainers to build powerful Web applications.
Popular Web applications place an emphasis on “Web transactions” in which a page request is received and a page is returned from a database definition or a HTML static file. Real-time content collection, aggregation, and especially “interactive” Web applications require a Web application architecture that has all of the advantages of a content management system (CMS) for delivering the mContainer definition, but is scalable enough to handle CPU-intensive requests, such as a request to find a single object within a page of objects. The mPortlets and mContainers of the present invention are very scalable as all of the message maps are downloaded to the client with each mPortlet so that all messaging can be handled by the client. An environment in which the system of the present invention may be preferably implemented will now be described.
The content appliance server(s) 410 identify, capture, and retrieve items of content. In the currently preferred embodiment, specialized content appliance servers are employed which are built from a tuned Linux kernel and configured to efficiently perform the task of retrieving content (e.g., from the World Wide Web). Further description of a system providing methods for dynamic capture and retrieval of content is provided in commonly-owned, copending U.S. patent application Ser. No. 09/780,993 titled “System and Method for Dynamic Content Retrieval”, the disclosure of which is hereby incorporated by reference. As capture requests increase with the number of users, additional content appliance servers 410 can are added to the cluster shown at
The Web application 420 is an Internet-enabled application that is operating on a Web server 430. The Web application 420 includes one or more messaging portlets and/or messaging containers created in accordance with the methodology of the present invention. Typically, a user (e.g., a developer, content manager, or other “knowledge worker”) creates one or more mPortlets using the system and methodology of the present invention. For example, the user may create the three mPortlets 461, 462, 463 shown at
As shown at
The mContainer(s) 460 and mPortlets 461, 462, 463 can be exported and run within a number of different content management systems (e.g., BEA and PlumTree content management systems) by appearing to be a standard HTML portlet or object. In addition, a messaging container (e.g., mContainer 460 as shown at
Messaging containers (mContainers) can communicate with other mContainers to produce complex but scalable Web applications drawing content in real-time from the Web, databases, flat files, and legacy Web applications. These mContainers can run on a client browser or be scheduled to run on the server by “agent” components. Also, mContainers can start on a client device, with messages sent to an “off screen” mContainer that will produce new content and send this new content directly to the user's browser on the client device. Offscreen mContainers can also be scheduled by an “agent” (or manager) to collect content and cache the new mPortlet in a “ready cache” of a Web application for quick rendering as previously described.
Implementation of Messaging Portlets
Browser Frame Organization
In the currently preferred embodiment of the present invention, portlets on a page are organized and implemented as separate HTML inline frames to facilitate independent loading. Each HTML inline frame operates as a separate portlet.
Listeners and Actioners
Messaging portlets have been designed so that there are no dependencies between individual mPortlets. When portlets are designated as messaging portlets they continue to operate in the same manner as they would if they were not designated as messaging portlets. In object oriented programming parlance, messaging portlets must be decoupled from each other while continuing to provide inter-portlet communication. This is a powerful feature because it allows mPortlets to be added to a page based on user choice and personalization rather than forcing the user to use a fixed set of tightly coupled portlets.
This decoupling of mPortlets is achieved by utilizing a central registration point for all mPortlets. In the currently preferred embodiment, the topmost browser window (as shown at
When the registrar 521 receives a notification from an actioner (e.g., actioner 531), it looks up the registered listeners (e.g., listeners 534, 536) and notifies each of them in turn. There is no necessity to register actioners with the registrar, since an actioner is not the target for the action it provides. However, it may be possible that an actioner is also listener for other pieces of information.
It should be noted that the registrar 521 does not directly affect the contents of the target portlets. Instead, the registrar passes a notification into the listener frame of the target. This is an important consideration that is necessary to cleanly decouple portlets. The registrar's job is only to register and notify. The actioner is responsible for packaging up the notification data and passing the notification event to the registrar. It is the responsibility of the listener to register and then process the notification.
In the currently preferred embodiment, the binding of a notification event to a listener's registration is done using a string value. When a listener registers with the registrar, the listener identifies a string value. When an actioner notifies the registrar it uses a string value. The string value is used to check each registration. The string value provided by the actioner is compared to the value of registered listeners. If the value matches a registered listener, then that listener is notified. There may be multiple registrations for each frame; however, each registration is generally associated with a different registration string value.
Register(targetframe, form, parameter, registeras): The “Register” function is used by a listener to register itself. The “targetframe” is used by the registrar when it needs to pass notifications to this frame. The “form” and “parameter” values identify a HTML FORM field that is the target for the data involved in the notification. The “registeras” field is the unique string against which this registration is associated.
UnRegister(targetframe, form, parameter, registeras): The “UnRegister” function is used by listeners to delete a previously made registration. This provides the opportunity for a frame to optionally turn on and off its ability to receive notifications from the registrar.
Notify(srcframe, notifyas, value) and NotifyAll(srcframe, notifyas, value): The “Notify” and “NotifyAll” functions are used by actioners to initiate a notification event. The “srcframe” value is not used by the registrar, but included for completeness. The “notifyas” value is used by the registrar to compare against the “registeredas” values for each registered listener. The value is the data associated with the notification. The difference between the Notify and the NotifyAll functions is that the Notify function will pass the notification only to the first registered listener associated with the “notifyas” value (i.e., the order of registrations is not guaranteed). The NotifyAll function passes the notification to all registered listeners associated with the “notifyas” function.
NotifyThis(form, parameter, value): The “NotifyThis” function is used by the registrar when a match is made between a notification and a listener. In the current implementation the target is assumed to be a HTML FORM field, that is a text field or a hidden field.
Similarly, the “NotifyAll” function contains the following code segment (with similar code in the Notify function):
As illustrated in the above code segments, the frame hierarchy is maintained by only executing functions of a given frame when the local variable indicates it is the top-most frame.
JSP Reference Generators
Actioner based on fixed source values (using NotifyAll).
Actioner based on a value sourced from a HTML FORM text or hidden field (using NotifyAll).
Listener based on a target value in a HTML FORM text or hidden field.
For example, the following illustrates a JSP code fragment which can be used to generate the appropriate HTML containing a link that is used to action a notification:
The above JSP code fragment for an actioner generates the following HTML code:
Likewise for a listener, the following JSP code fragment is included in the target frame source:
The above JSP code fragment for a listener generates the following HTML code:
Example of Web Application Based on Messaging Portlets
To illustrate the flexibility of the design and methodology the present invention, the following discussion describes a small Web application that is based on the use of messaging portlets. In this example, the Web application is built using three messaging portlets that can cooperate based on the dynamic content they contain. These three portlets are as follows:
Symbol List Portlet: The Symbol List Portlet is an aggregated mPortlet built from a single XML element that makes a call to a URL (which happens to be a Java server page) that reads a database table for a list of company stock symbols. The resulting XML is transformed into HTML using a XSL transformation based on a defined XSL template. The XSL transformation forms a HTML table with a separate row for each different company stock symbol.
Address Portlet: The Address Portlet is another aggregated mPortlet built from a single XML element. However the Address Portlet uses a single parameter value in the URL to parameterize the company stock symbol that is used to read the company's address from the same database. Another XSL transformation defined as an XML Template is used to display the address as a set of HTML FORM text entry fields. The address includes a Post Code (or zip code) field.
Map Portlet: The Map Portlet is an aggregated Portlet built from a single Web element. The Web element is a capture of the map sourced from a Post Code entry. Only the Map graphic and some of the map controls have been captured from the original page. The Post Code has been registered as the required entry parameter for this Map Portlet.
Conceptually, each of these three portlets performs a discrete function. However, when defined as messaging portlets they can work together to relate the information that each is presenting with information presented by the other messaging portlets. For example, the Symbol List Portlet, when implemented as a messaging portlet, may be defined to represent an actioner which creates a notification event based on the click of an actioner icon (or hot spot) that is associated with each company stock symbol. The Address Portlet represents both a listener and an actioner. The Address Portlet registers for the notification of a stock symbol event type and re-posts its own HTML FORM to re-populate the portlet's address information based on the stock symbol received from the notification. The actioner of the Address Portlet creates a notification event based on the click of an actioner icon (or hot spot) associated with the Post Code (or zip code) field. The Map Portlet represents a listener which is registered to receive notification of a Post Code event type. When a Post Code event type occurs, the Map Portlet re-posts its own HTML FORM to re-populate the map information based on the Post Code received from the notification.
Configuration of Messaging Portlets
For example, the standalone portlet for the above-described Symbol List Portlet can be defined against a standard one row by one column (1×1) portlet template. However, for a messaging portlet a custom user interface XSL is created so that it outputs an actioner icon (hot spot) for each company symbol returned. The user interface XSL for a sample Symbol List Portlet is shown below:
The actioner “hot spot” code which provides for sending a message in response to a user selecting (e.g., clicking on) the hot spot (actioner) is shown above at lines 12-16.
The example Address Portlet is also enclosed in a one column by one row (1×1) HTML Template. The HTML Template code for this sample Address Portlet is shown below:
This above HTML Template is the same as the original standard 1×1 HTML portlet except for the addition of the definitions of the listener for the “symbol” notification and for the creation of an actioner icon (hot spot) that actions the Post Code notification at lines 7-26 above.
The below example Map Portlet is also housed in another custom one column by one row (1×1) HTML Template.
The HTML Template code for this sample Map Portlet is shown below:
This template is also the same as the original standard 1×1 HTML portlet except for the addition of the definitions of the listener for the “Post Code” notification shown at lines 7-21 above.
The FORM text field, the portlet's input parameter, was derived from a preview of the portlet prior to assigning it this new HTML Template as described above. In this case it is called “null?null&&csz&&NNNN” as provided above at lines 12 and 18.
Example of Click Across Portlets
As shown at
The user can also “Click-Across” from the Symbol List mPortlet 620 to cause different address information to be displayed in the Address mPortlet. For example if the user clicked on the action 612 associated with the symbol “IBM”, the symbol “IBM” is sent by the Symbol List mPortlet 610 to the Address mPortlet 620. In other words, the symbol associated with the actioner hot spot 612 is assigned to the Address symbol parameter, and the Address mPortlet 620 is then automatically refreshed based on the new parameter. As a result the address of the company associated with the selected symbol would be displayed in the Address mPortlet 620.
The user can also “Click-Across” from the Address mPortlet 620 to the Map mPortlet 630 in a similar fashion. Selecting the actioner “hot spot” 622 assigns the Post Code associated with the actioner hot spot to the “csz” parameter 633 of the Map mPortlet 630. The Map mPortlet 630 is then automatically refreshed based on the new csz parameter to display a map centered on this Post Code.
The flexibility of the design of the system of the present invention means that other messaging portlets that listen for the same notification may also be easily added to a page (e.g., page 600). Other mPortlets that were added to the page can also refresh themselves in response to a Click-Across action in a similar fashion. For example, a Stock Price messaging portlet could be added to listen for the symbol notification from the Symbol List mPortlet. In this case when a Symbol List mPortlet actioner is clicked it would refresh both the Address mPortlet and the Stock Price mPortlet with the new symbol and content based on that symbol would be displayed in both of these mPortlets.
Creation of Messaging Portlets
The following discussion describes how existing portlets or “elements” can be converted into messaging portlets or elements (i.e., mPortlets). The following discussion uses the example of the conversion of a Web element or portlet into a messaging portlet. However, the methodology of the present invention may also be used in conjunction with other elements or portlets, including database elements and XML elements.
Web portlets (sometimes referred to in the following discussion as “elements”) created with a content capture workbench provided by the system of the currently preferred embodiment can be converted into a messaging portlet (sometimes referred to below as an “mElement”) by selecting the desired element and then selecting “mElement” from the pop-up menu displayed with a right-mouse click. The messaging element wizard provided in the currently preferred embodiment of the system provides a “wizard page” enabling a user (e.g., developer or other knowledge worker) to preview the desired element and select from a number of messaging strategies to add actions to the element. In many cases the selection of the desired messaging strategy is obvious. However, it is possible to have a single element that contains several different combinations of anchors, tables, and forms. In this event, the user will need to consider the action desired and apply the appropriate strategy. Current messaging element strategies supported in the currently preferred embodiment of the present invention include the following:
“Anchor” objects. An anchor object displayed in the wizard page may be used to add messaging element actions to Web anchors and links within an element.
“Grid” objects. A grid object displayed in the wizard page can be used to add messaging element actions to Web objects with “column and row” formatting. These elements are usually the result of a grid capture that has been modified with “grid rule” formatting.
“Form” objects such as Web “FORM” tags. These objects can be captured using a “CELL” capture strategy or a “FORM” strategy in the Web capture workbench provided by the system of the currently preferred embodiment.
“Database” objects for elements that have been created using a database capture strategy.
“Custom” objects that are unique to a particular installation.
Using the wizard, the user may select the desired messaging element strategy and then click on the “Next” button to continue the creation of a new messaging element (mPortlet).
After the user selects the “Next” button, he or she may continue implementing one of the following mElement messaging strategies currently supported in the system of the present invention:
Link/Anchor Action Message Strategies. A Link/Anchor page is provided which includes the following three features: a “preview area” displays a view of the original content with additional icons to indicate what message actions are being added; an “Assign Message Actions” table allows the user to define message actions with a pop-up menu and to assign output message names; and an “action icon” (e.g., a red check mark icon) which is displayed next to message elements that are “active” and ready to send messages. Using the action icon allows the original anchor link to remain working within the element.
In operation, clicking on the anchor and the link of a given element behaves as if there are no messaging actions within (or associated with) the given element. However, when the “action icon” is selected, the message containing the text of the link and the output message name is sent to the messaging element's container and then broadcast to all other listening elements.
The “Assign Message Action” table's pop-up menu currently has the following menu items and actions:
No Action: The link has no messaging actions.
Send: Send this link and output message when the “action icon” (e.g., check mark icon) is selected (e.g., clicked on).
Send All: Enable all links in the element for action so that each link will have an “action icon” icon and output message.
Clear: Clear all messaging actions from this element.
When messaging actions have been associated with messaging elements (mPortlets), a user may select a “Finish” button on the wizard. Upon pressing Finish, if a messaging element (mportlet) is actionized, an “action icon” (e.g., a red check mark icon) is visible in the editor's preview page.
Web Application Wizard
The system of the currently preferred embodiment also provides a “Web Application Builder” tool that can be used to create Web applications using a frameset to contain multiple elements. Web applications provide a container (i.e., mContainer) for messaging elements that communicate with each other. Elements (portlets) captured from different sources with varying strategies can be made to communicate with each other using the above-described messaging element wizard and then combined using the Web Application Builder to create applications that provide rich functionality. The Web Application Builder also allows users to select from different pre-defined frame layouts to design their Web application.
The following discussion describes how a Web application can be constructed using the Web Application Builder tool or wizard. This discussion assumes that all of the elements (mPortlets) that are to be used as part of the Web application using the Web Application Builder wizard must have already been created.
In the system of the currently preferred embodiment, the Web Application Builder wizard can be started by selecting a “Web Application Builder” icon from the toolbar. The wizard can also be opened by selecting an “Open New Wizard” icon from the toolbar and then selecting “Content Development” and “WebApp Builder” from a dialog box. Alternatively, a user can select a “WebApp Builder” menu item from a Content Capture Workbench menu provided by the system. After the wizard is started, a user can select a frame layout for the Web application (e.g., by choosing an icon of a particular type of frame layout from a menu of choices and pressing a “Next” button in the wizard).
Depending on the layout selected, the user may then need to select the number of elements. For example, a 3-frame layout will require 3 elements to be selected. Currently, elements may be selected by highlighting a project name to view the contents on a right-hand window pane. Pressing a checkbox next to the project name selects all the elements by default but it does not make the elements viewable. An indication is provided when all of the elements have been selected within a project. Elements may be deselected by pressing “Deselect All”. In the currently preferred embodiment, the exact number of elements required for the frame layout must be selected before the wizard allows the user to continue.
After the necessary elements have been selected, a “preview” pane contains an outline of how the elements will be displayed once the Web application is completed. The positioning of the elements can be altered by mapping the frame name to the name of the element. Drop down menus allow the option to choose another location for the element. The preview pane may be referenced to find out the mapping schema for the element numbers for a particular frame layout. The preview pane also reflects any changes made to the positioning of the elements. A user can also select a “Preview Content” option to view the Web application using the actual elements (including their contents). The completed application can then be saved. In the currently preferred embodiment a “save” page is provided which enables a user to save the elements and place them in the project of their choice. The operations of the system of the present invention will next be described in greater detail.
Overview of Basic Methodology
The following discussion uses as an example the conversion of one or more portlets in an existing static portal into interactive messaging portlets. The process begins at step 701 with the mapping of message actions to one or more existing portlets. For example, a messaging element wizard provided in the currently preferred embodiment of the present invention may be used to preview the portlets to be converted to mPortlets and to select and add messaging actions to these portlets (e.g., adding “action icons” to “actioner” mPortlets that may be selected to cause actions to occur in one or more “listener” m Portlets).
A messaging container (mContainer) is typically created as a container for the mPortlet and the mContainer and mPortlets are implemented (e.g., as part of a content management application or other Web application). As a Web page containing the mContainer and mPortlets is loaded (e.g., in a browser on a client device), at step 702 the listener mPortlets register with the registrar and the action icons or “hot spots” are generated and displayed to “actionize” the actioner mPortlets.
A user may then select (e.g., click on) a particular action icon of an actioner mPortlet. In response to a user selecting a particular action icon of an actioner mPortlet, at step 703 the actioner mPortlet sends a message (notification event) to the registrar. For example, a messaging portlet may be defined to represent an actioner which creates a notification event based on the click of an actioner icon (or hot spot) that is associated with a company stock symbol. When the actioner icon is selected, the actioner mPortlet packages up the notification data (e.g., information about the company having the stock symbol) and passes the notification event to the registrar.
When the registrar receives a notification event from an actioner mPortlet, at step 704 the registrar looks up the registered listener mPortlets that registered to receive this notification. In the currently preferred embodiment, the binding of a notification event to a listener's registration is done using a string value. When a listener registers with the registrar, the listener identifies a string value. When an actioner issues a notification event to the registrar it also includes a string value. The string value provided by the actioner is compared to the value of registered listeners. At step 705, the registrar notifies each of the registered listeners (i.e., those with matching values) by passing a notification into the listener frame of each registered listener mPortlet. At step 706, the notification is processed by the registered listener mPortlet(s). For example, an address of the company having the stock symbol may be retrieved and displayed in a listener mPortlet in response to the selection of an actioner associated with the stock symbol in an actioner mPortlet.
- mPortlet.html Loaded into a Hidden Frame of the Container Portlet
The currently preferred embodiment of the present invention utilizes two code libraries to pass messages between the messaging portlet elements.
The above “mPortlet.html” has the responsibility to wait for “registration” of each of the content portlets and to send any messages received from a content portlet to each of the “listening” portlets registered to receive such messages.
mListen.js File Included with Each Content Element
As also shown at
Each Content frame's mListen.js routines will also wait for (i.e., listen for) messages from the mPortlet.html of the hidden frame (registrar) and insert data received into the appropriate “INPUT FORM” field. This typically causes the content of the frame to be dynamically updated based upon the message received from another frame. As illustrated at
While the invention is described in some detail with specific reference to a single preferred embodiment and certain alternatives, there is no intent to limit the invention to that particular embodiment or those specific alternatives. For instance, the system and methodology of the present invention may also be used to enhance the ability to conduct information searches by allowing the results of a search performed by a first messaging portlet to be sent to another search query in another portlet on the same page. As another example, the present invention may be used to enhance the peer to peer sharing of information between two (or more) individuals. Individuals could, for instance, exchange messages in a portlet while also sharing and/or updating information in other messaging portlets on the same page. The interactive nature of messaging portlets enables the development and implementation of a wide range of Web applications facilitating information exchanges amongst various users and devices. Accordingly, those skilled in the art will appreciate that modifications may be made to the preferred embodiment without departing from the teachings of the present invention.
1. A method for interactive content retrieval and display, the method comprising:
- providing a plurality of portlets for retrieval of content for display in a user interface;
- mapping a message action to a first portlet to create a messaging portlet for sending a message in response to user interaction with the messaging portlet;
- creating a listener portlet by registering a second portlet to receive messages from the messaging portlet; and
- in response to user interaction with the messaging portlet, retrieving particular content for display in the user interface based on the message received by the listener portlet from the messaging portlet.
2. The method of claim 1, wherein said plurality of portlets comprise a portal.
3. The method of claim 1, wherein a portlet retrieves content from a particular source.
4. The method of claim 1, wherein a portlet displays content in a Web page.
5. The method of claim 4, wherein the Web page is implemented using a markup language.
6. The method of claim 5, wherein the markup language comprises a selected one of HyperText Markup Language (HTML), Extensible Markup Language (XML), Extensible Hypertext Markup Language (XHTML), and Compact HyperText Markup Language (cHTML).
7. The method of claim 1, wherein the first portlet comprises a markup language anchor.
8. The method of claim 1, wherein said retrieving step includes retrieving a selected one of a Web page, a portion of a Web page, database content, spreadsheet data, documents, files, and information from a Common Gateway Interface.
9. The method of claim 1, wherein said user interface comprises a browser interface.
10. The method of claim 1, wherein said messaging portlet is structured as a HyperText Markup Language (HTML) inline frame.
11. The method of claim 1, wherein the listener portlet is structured as a HyperText Markup Language (HTML) inline frame.
12. The method of claim 1, wherein the listener portlet registers with a registrar to receive the message from the messaging portlet.
13. The method of claim 12, wherein said registrar is located in a browser window.
14. The method of claim 13, wherein the browser window comprises a topmost browser window of a Web page.
17. The method of claim 1, wherein the message received from said messaging portlet comprises a selected one of an identifier, text, or an attribute.
18. The method of claim 1, further comprising:
- creating a second listener portlet by registering a third portlet to receive messages from said messaging portlet; and
- in response to user interaction with said messaging portlet, retrieving particular content for display in the user interface based on the message received by the second listener portlet from the messaging portlet.
19. The method of claim 1, further comprising:
- mapping a message action to the listener portlet;
- creating a second listener portlet by registering a third portlet to listen for messages from the listener portlet; and
- in response to the message received by the listener portlet from the messaging portlet, retrieving particular content for display in the user interface based on the message received by the second listener portlet from the listener portlet.
20. A computer-readable medium having processor-executable instructions for performing the method of claim 1.
21. A downloadable set of processor-executable instructions for performing the method of claim 1.
22. A system for interactive content retrieval and display, the system comprising:
- a user interface for display of content;
- an actioner module for display of content in the user interface and sending a message based on user interaction with said actioner module;
- a registrar for receiving the message from said actioner module and routing the message to at least one listener module registered to receive the message; and
- at least one listener module registered for receiving the message from the registrar and retrieving content for display in the user interface based on the message sent by the actioner module.
23. The system of claim 22, wherein said actioner module comprises a portlet.
24. The system of claim 23, wherein said portlet retrieves content from a particular source.
25. The system of claim 22, wherein at least one listener module displays content in a Web page.
26. The system of claim 25, wherein the Web page is implemented using a markup language.
27. The system of claim 26, wherein the markup language comprises a selected one of HyperText Markup Language (HTML), Extensible Markup Language (XML), Extensible Hypertext Markup Language (XHTML), and Compact HyperText Markup Language (cHTML).
28. The system of claim 22, wherein said actioner module comprises a markup language anchor.
29. The system of claim 22, wherein said at least one listener module retrieves a selected one of a Web page, a portion of a Web page, database content, spreadsheet data, documents, files, and information from a Common Gateway Interface.
30. The system of claim 22, wherein said user interface comprises a browser interface.
31. The system of claim 22, wherein said actioner module is structured as a HyperText Markup Language (HTML) inline frame.
32. The system of claim 22, wherein said at least one listener module is structured as a HyperText Markup Language (HTML) inline frame.
33. The system of claim 22, wherein said at least one listener module registers with the registrar to receive the message from the actioner module.
34. The system of claim 33, wherein the registrar is located in a browser window.
35. The system of claim 34, wherein the browser window comprises a topmost browser window of a Web page.
38. The system of claim 22, wherein the message received by said at least one listener module comprises a selected one of an identifier, text, or an attribute.
39. The system of claim 22, further comprising:
- a module for mapping a message action to the actioner portlet.
40. The system of claim 22, further comprising:
- a listener messaging module registered to receive the message from the actioner module and send a message based on the message received from the actioner module.
41. The system of claim 40, wherein said listener messaging module retrieves content for display in the user interface based on the message sent by the actioner module.
42. A method for collaborative retrieval and display of information in a Web page, the method comprising:
- providing a plurality of elements for retrieval and display of information in a Web page;
- creating a registrar for receiving a message and routing the message to at least one listening element registered to receive the message;
- associating a message action with a first element for sending a message in response to user interaction with the first element;
- registering at least one listener element with the registrar for receiving a message sent by the first element; and
- in response to user interaction with the first element, displaying particular information on the Web page based on the message received by said at least one listener element from the first element.
43. The method of claim 42, wherein said plurality of elements comprise a portal.
44. The method of claim 42, wherein an element retrieves information from a particular source.
45. The method of claim 42, wherein an element comprises a markup language element.
46. The method of claim 42, wherein the first element comprises a markup language anchor.
47. The method of claim 42, wherein said displaying step includes displaying a selected one of a Web page, a portion of a Web page, database content, spreadsheet data, documents, files, and information from a Common Gateway Interface.
48. The method of claim 42, wherein said Web page is displayed by a Web browser.
49. The method of claim 42, wherein said first element is structured as a HyperText Markup Language (HTML) inline frame.
50. The method of claim 42, wherein said at least one collaborative element is structured as a HyperText Markup Language (HTML) inline frame.
51. The method of claim 42, wherein said creating a registrar step includes creating the registrar in a browser window.
52. The method of claim 51, wherein the browser window comprises a topmost browser window of a Web page.
54. The method of claim 42, wherein the message received by said at least one listener element comprises a selected one of an identifier, text, or an attribute.
55. The method of claim 42, wherein the first element comprises a listening element registered to receive a message from a particular element on the Web page.
56. The method of claim 55, wherein the first element sends a message when it receives a message from said particular element.
57. The method of claim 42, wherein at least some of said listener elements have associated message actions for sending messages to other elements.
58. A computer-readable medium having processor-executable instructions for performing the method of claim 42.
59. A downloadable set of processor-executable instructions for performing the method of claim 42.