The present invention is related to the following applications entitled Method and Apparatus for Data Hub Objects, Curtis et al., Attorney Docket AUS920060516US1, Ser. No. ______; Method for Defining a Wiki Page Layout using a Wiki Page, Curtis et al., Attorney Docket AUS920060517US1, Ser. No. ______; Method for Extending the Capabilities of a Wiki Environment, Curtis et al., Attorney Docket AUS920060518US1, Ser. No. ______; Method for Programmatically Hiding and Displaying Wiki Page Layout Sections, Curtis et al., Attorney Docket AUS920060519US1, Ser. No. ______; Method for Inheriting a Wiki Page Layout for a Wiki Page, Curtis et al., Attorney Docket AUS920060520US1, Ser. No. ______; Method for Processing a Web Page for Display in a Wiki Environment, Curtis et al., Attorney Docket AUS920060521US1, Ser. No. ______; Processing Model of an Application Wiki, Curtis et al., Attorney Docket AUS920060522US1, Ser. No. ______; Generic Frequency Weighted Visualization Component, Curtis et al., Attorney Docket AUS920060523US1, Ser. No. ______; Relevant Term Extraction and Classification for Wiki Content, Curtis et al., Attorney Docket AUS920060524US1, Ser. No. ______; Method and Apparatus for Client Wiring Model, Curtis et al., Attorney Docket AUS920060525US1, Ser. No. ______; Method and Apparatus for Server Wiring Model, Curtis et al., Attorney Docket AUS920060526US1, Ser. No. ______; and Method and Apparatus for Client and Server Interaction, Curtis et al., Attorney Docket AUS920060527US1, Ser. No. ______; all filed even date hereof, all assigned to a common assignee, and all of which are incorporated herein by reference.
1. Technical Field
The present invention relates generally to an improved data processing system and in particular to a method and apparatus for a programming model. Still more particularly, the present invention relates to a computer implemented method, apparatus, and computer usable program code for manipulating content using a browser.
2. Description of the Related Art
The Internet is a global network of computers and networks joined together by gateways that handle data transfer in the conversion of messages from a protocol of the sending network to a protocol of the receiving network. On the Internet, any computer may communicate with any other computer in which information travels over the Internet through a variety of languages referred to as protocols. The set of protocols most commonly used on the Internet is called transmission control protocol/Internet protocol (TCP/IP).
The Internet has revolutionized communications and commerce as well as being a source of both information and entertainment. One type of software that has become more frequently used is Wiki software. Wiki software is a type of collaborative software that runs a Wiki environment. This software is provided in a shared environment that may be accessed through an interface by a group of users. A Wiki application is a type of website that allows users to manipulate content. Users may add, remove, or otherwise edit and change content very quickly and easily. Wiki applications are often used as an effective tool for collaborative writing. The current use of Wiki applications is directed towards collaborative content creation, such as online encyclopedias or other knowledge bases. Users typically can create content in a shared environment. In this environment, revisions of pages are saved to allow previous versions to be restored. Further, mark-up shortcuts are provided for creating inter-page links. Further, a “what you see is what you get” (WYSIWYG) editing mode/editor is often utilized.
The aspects of the present invention provide a computer implemented method, apparatus, and computer usable program code to determine argument availability for event firing. The process aggregates argument data from a set of sources to form an aggregate data set. The process generates a list of minimum sufficient arguments for firing an event to form a set of minimum arguments. The process compares the aggregate data set to the set of minimum arguments to determine whether the set of minimum arguments are available. The process triggers the command to send the event to a data hub for processing, in response to determining that the set of minimum arguments are available.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
FIG. 1 is a pictorial representation of a network of data processing systems in which illustrative embodiments of the present invention may be implemented;
FIG. 2 is a block diagram of a data processing system in which illustrative embodiments of the present invention may be implemented;
FIG. 3 is a diagram illustrating components for use in generating and using Wiki applications in accordance with an illustrative embodiment of the present invention;
FIG. 4 is a diagram illustrating a Wiki architecture in accordance with an illustrative embodiment of the present invention;
FIG. 5 is a diagram illustrating dataflow in rendering a page in accordance with an illustrative embodiment of the present invention;
FIG. 6 is a diagram illustrating components on a client and server for a Wiki application in accordance with an illustrative embodiment of the present invention;
FIG. 7 is an exemplary screen of display for dragging live content in accordance with an illustrative embodiment of the present invention;
FIG. 8 is a screen of display for editing properties of a command in accordance with an illustrative embodiment of the present invention;
FIG. 9 is a page tree view in accordance with an illustrative embodiment of the present invention;
FIG. 10 is a screen of display for a Wiki page in accordance with an illustrative embodiment of the present invention;
FIG. 11 is a block diagram of an abstract syntax tree in accordance with an illustrative embodiment of the present invention;
FIG. 12 is a block diagram of commands in accordance with an illustrative embodiment of the present invention;
FIG. 13 is a diagram showing property editing components in accordance with an illustrative embodiment of the present invention;
FIG. 14 is a diagram illustrating a data flow between commands on a client and server for a Wiki application in accordance with an illustrative embodiment of the present invention;
FIG. 15 is a diagram illustrating a data flow between commands on a server during an initial page render process in accordance with an illustrative embodiment of the present invention;
FIG. 16 is a diagram illustrating a Wiki page generated in response to a page request from a user in accordance with an illustrative embodiment of the present invention;
FIG. 17 is a diagram illustrating a rendered page displayed at a client browser in accordance with an illustrative embodiment of the present invention;
FIG. 18 is a diagram illustrating a data flow between components on a client-side data hub after a new page is loaded and displayed at a client browser in accordance with an illustrative embodiment of the present invention;
FIGS. 19A and 19B is a diagram illustrating a data flow between a client-side data hub and a server-side data hub during a page update in accordance with an illustrative embodiment of the present invention;
FIG. 20 is a diagram illustrating a message flow between a server-side data hub and a client-side data hub during a page update in accordance with an illustrative embodiment of the present invention;
FIG. 21 is a diagram illustrating a server-side data hub object in accordance with an illustrative embodiment of the present invention;
FIG. 22 is a diagram illustrating a client-side data hub object in accordance with an illustrative embodiment of the present invention;
FIG. 23 is a block diagram illustrating the process of embedding Wiki page content into the body of a Wiki layout page in accordance with an illustrative embodiment of the present invention;
FIG. 24 is a block diagram depicting checkboxes for determining visibility of content of page components in accordance with an illustrative embodiment of the present invention;
FIG. 25 is a flowchart of a process for creating a Wiki page in accordance with an illustrative embodiment of the present invention;
FIG. 26 is a flowchart of a process for displaying a page in accordance with an illustrative embodiment of the present invention;
FIG. 27 is a flowchart of a process for generating a page tree view in accordance with an illustrative embodiment of the present invention;
FIG. 28 is a flowchart of a process for dragging live content in accordance with an illustrative embodiment of the present invention;
FIG. 29 is a flowchart of a process for combining content of Wiki pages in accordance with an illustrative embodiment of the present invention;
FIG. 30 is a flowchart of a process for editing a command in accordance with an illustrative embodiment of the present invention;
FIG. 31 is a flowchart of a process for rendering a Wiki command in accordance with an illustrative embodiment of the present invention;
FIG. 32 is a flowchart of a preliminary process for property editing in accordance with an illustrative embodiment of the present invention;
FIG. 33 is a flowchart of a process for property editing in accordance with an illustrative embodiment of the present invention;
FIG. 34 is a flowchart of a process selecting a property editor in accordance with an illustrative embodiment of the present invention;
FIG. 35 is a flowchart of a process for deleting a page in accordance with an illustrative embodiment of the present invention;
FIG. 36 is a flowchart of a process for revising a page in accordance with an illustrative embodiment of the present invention;
FIG. 37 is a flowchart of a process for copying a page in accordance with an illustrative embodiment of the present invention;
FIG. 38 is a flowchart of a process for renaming a page in accordance with an illustrative embodiment of the present invention;
FIG. 39 is a flowchart of a process for undeleting a page in accordance with an illustrative embodiment of the present invention;
FIG. 40 is a flowchart of a process for palette construction in accordance with an illustrative embodiment of the present invention;
FIG. 41 is a flowchart of a process for configuration in accordance with an illustrative embodiment of the present invention;
FIG. 42 is a flowchart of a process for export in accordance with an illustrative embodiment of the present invention;
FIG. 43 is a flowchart of a process for import in accordance with an illustrative embodiment of the present invention;
FIG. 44 is a flowchart of a process for retrieving and parsing a tree in accordance with an illustrative embodiment of the present invention;
FIG. 45 is a process for processing a web page for display in a Wiki in accordance with an illustrative embodiment of the present invention;
FIG. 46 is a flowchart of processing events in accordance with an illustrative embodiment of the present invention
FIG. 47 is a flowchart of an operation occurring when a server-side data hub object is instantiated in accordance with an illustrative embodiment of the present invention;
FIG. 48 is a flowchart of an operation occurring when a client-side data hub object is instantiated in accordance with an illustrative embodiment of the present invention;
FIG. 49 is a flowchart of an operation occurring when a server-side data hub receives a request to process an event from a client-side data hub in accordance with an illustrative embodiment of the present invention;
FIG. 50 is a flowchart of an operation occurring when a producer command processes an event in accordance with an illustrative embodiment of the present invention;
FIG. 51 is a flowchart outlining an operation occurring when a consumer command processes an event in accordance with an illustrative embodiment of the present invention;
FIG. 52 is a flowchart of an operation occurring when a client-side data hub receives an event in accordance with an illustrative embodiment of the present invention;
FIG. 53 is a flowchart of an operation occurring when a server-side data hub processes an event in accordance with an illustrative embodiment of the present invention;
FIG. 54 is a flowchart of an operation occurring when a client-side data hub determines whether to send an event to a server for processing in accordance with an illustrative embodiment of the present invention;
FIG. 55 is a flowchart of an operation occurring when a server-side data hub receives an event from a client-side data hub as a result of a processClientEvent method call in accordance with an illustrative embodiment of the present invention;
FIG. 56 is a flowchart of an operation occurring when a Wiki argument object performs a minimum sufficient argument process in accordance with an illustrative embodiment of the present invention;
FIG. 57 is a flowchart illustrating an operation ocurring when a Wiki argument object determines if the minimum required arguments of a command are set in accordance with an illustrative embodiment of the present invention;
FIG. 58 is a flowchart illustrating a setCheckArguments method for detecting if an argument/available event should be fired in accordance with an illustrative embodiment of the present invention;
FIG. 59 is a flowchart illustrating the operation of defining a Wiki page layout with a Wiki page in accordance with an illustrative embodiment of the present invention;
FIG. 60 is a flowchart of the operation of rendering a Wiki page in accordance with an illustrative embodiment of the present invention;
FIG. 61 is an illustration of class definition for a server-side data hub object class in accordance with an illustrative embodiment of the present invention;
FIG. 62 is an illustration of a set of method interfaces for a class of data hub management methods in accordance with an illustrative embodiment of the present invention;
FIG. 63A is an illustration of a set of method interfaces for a class of producer and consumer methods in accordance with an illustrative embodiment of the present invention;
FIG. 63B is an illustration of a set of method interfaces for a class of topic methods in accordance with an illustrative embodiment of the present invention;
FIG. 64 is an illustration of a set of method interfaces for a class of event processing methods in accordance with an illustrative embodiment of the present invention;
FIG. 65 is an illustration of a set of method interfaces for a class of command management methods in accordance with an illustrative embodiment of the present invention;
FIG. 66 is an illustration of a class definition for a client-side data hub object class in accordance with an illustrative embodiment of the present invention;
FIG. 67 is an illustration of a set of method interfaces for a class of producer and consumer methods in accordance with an illustrative embodiment of the present invention;
FIG. 68 is an illustration of a set of method interfaces for topic methods in accordance with an illustrative embodiment of the present invention;
FIG. 69 is an illustration of a set of method interfaces for event processing methods in accordance with an illustrative embodiment of the present invention;
FIG. 70 is an illustration of a set of method interfaces for command management methods in accordance with an illustrative embodiment of the present invention;
FIG. 71 is an illustration of a class definition and method interfaces for a class of data hub topic objects in accordance with an illustrative embodiment of the present invention;
FIG. 72 is an illustration of a class definition and method interfaces for a class of data hub event objects in accordance with an illustrative embodiment of the present invention;
FIG. 73 is an illustration of a class definition for a Wiki argument object class in accordance with an illustrative embodiment of the present invention; and
FIG. 74 is an illustration of pseudocode of an algorithm to detect whether to fire an argument/available event in accordance with an illustrative embodiment of the present invention.
With reference now to the figures and in particular with reference to FIGS. 1-2, a description of corresponding diagrams of data processing environments is provided in which illustrative embodiments of the present invention may be implemented. It should be appreciated that FIGS. 1-2 are only exemplary and are not intended to assert or imply any limitation with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environments may be made.
With reference now to the figures, FIG. 1 depicts a pictorial representation of a network of data processing systems in which illustrative embodiments of the present invention may be implemented. Network data processing system 100 is a network of computers in which embodiments may be implemented. Network data processing system 100 contains network 102 , which is the medium used to provide communications links between various devices and computers connected together within network data processing system 100 . Network 102 may include connections, such as wire, wireless communication links, or fiber optic cables.
In the depicted example, server 104 and server 106 connect to network 102 along with storage unit 108 . In addition, clients 110 , 112 , and 114 connect to network 102 . These clients 110 , 112 , and 114 may be, for example, personal computers or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 110 , 112 , and 114 . Clients 110 , 112 , and 114 are clients to server 104 in this example. Network data processing system 100 may include additional servers, clients, and other devices not shown.
In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, governmental, educational and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN). FIG. 1 is intended as an example, and not as an architectural limitation for different embodiments.
With reference now to FIG. 2, a block diagram of a data processing system is shown in which illustrative embodiments of the present invention may be implemented. Data processing system 200 is an example of a computer, such as server 104 or client 110 in FIG. 1, in which computer usable code or instructions implementing processes of the various illustrative embodiments of the present invention may be located.
In the depicted example, data processing system 200 employs a hub architecture including a north bridge and memory controller hub (MCH) 202 and a south bridge and input/output (I/O) controller hub (ICH) 204 . Processor 206 , main memory 208 , and graphics processor 210 are coupled to north bridge and memory controller hub 202 . Graphics processor 210 may be coupled to the MCH through an accelerated graphics port (AGP), for example.
In the depicted example, local area network (LAN) adapter 212 is coupled to south bridge and I/O controller hub 204 , audio adapter 216 , keyboard and mouse adapter 220 , modem 222 , read only memory (ROM) 224 , universal serial bus (USB) ports and other communications ports 232 , and PCI/PCIe devices 234 are coupled to south bridge and I/O controller hub 204 through bus 238 , and hard disk drive (HDD) 226 and CD-ROM drive 230 are coupled to south bridge and I/O controller hub 204 through bus 240 . PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards, and PC cards for notebook computers. ROM 224 may be, for example, a flash binary input/output system (BIOS). Hard disk drive 226 and CD-ROM drive 230 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. A super I/O (SIO) device 236 may also be coupled to south bridge and I/O controller hub 204 through bus 238 as shown.
In the illustrative embodiment of FIG. 2, an operating system runs on processor 206 and coordinates and provides control of various components within data processing system 200 . The operating system may be a commercially available operating system such as Microsoft® Windows® XP (Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both). An object oriented programming system, such as the Java™ programming system, may run in conjunction with the operating system and provides calls to the operating system from Java programs or applications executing on data processing system 200 (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both).
Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as hard disk drive 226 , and may be loaded into main memory 208 for execution by processor 206 . The processes of the illustrative embodiments may be performed by processor 206 using computer-executable instructions, which may be located in a memory such as, for example, main memory 208 , read only memory 224 , or in one or more peripheral devices.
The hardware in FIGS. 1-2 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted in FIGS. 1-2. Also, the processes of the illustrative embodiments may be applied to a multiprocessor data processing system.
In some illustrative examples, data processing system 200 may be a personal digital assistant (PDA), which is generally configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data. A bus system, such as bus 238 and 240 , may be comprised of one or more buses, such as a system bus, an I/O bus and a PCI bus. Of course the bus system may be implemented using any type of communications fabric or architecture that provides for a transfer of data between different components or devices attached to the fabric or architecture. A communications unit may include one or more devices used to transmit and receive data, such as a modem or a network adapter. A memory may be, for example, main memory 208 or a cache such as found in north bridge and memory controller hub 202 . A processing unit may include one or more processors or CPUs. The depicted examples in FIGS. 1-2 and above-described examples are not meant to imply architectural limitations. For example, data processing system 200 also may be a tablet computer, laptop computer, or telephone device in addition to taking the form of a PDA.
In the illustrative examples, server 104 may host a Wiki application. The environment at server 104 allows clients, such as clients 110 , 112 , and 114 to collaborate and develop applications in accordance with an illustrative embodiment. These applications may include, for example, weather related applications, registrations and rosters for schools, e-mail applications, and other types of business oriented applications. The different embodiments may include processes at the server side, client side, or both in providing a collaborative environment to develop Wiki applications in accordance with an illustrative embodiment.
The illustrative embodiments recognize that current Wiki applications are not suited for collaborative development of applications beyond collaboration of text and files as a knowledgebase or document.
Turning now to FIG. 3, a diagram illustrating components for use in generating and using Wiki applications is depicted in accordance with an illustrative embodiment of the present invention. In this example, a user may interact with client environment 300 to generate and use applications supported by Wiki environment 302 . Client environment 300 is a software application or environment executing on a client, such as client 110 in FIG. 1. Wiki environment 302 executes on a data processing system, such as server 104 in FIG. 1.
In these examples, a user at client environment 300 may send a request to Wiki environment 302 for a page. The user makes the request through a browser within client environment 300 in these examples. Wiki environment 302 returns the page to the user. In these illustrative examples, the page includes JavaScript that enables the user to manipulate and select content for a page to be generated. In the illustrative embodiments, these pages are collaborative Web pages that provide user access to applications. These applications are collaborative applications that may be used and modified by users at client computers.
In particular, the different illustrative embodiments provide a method and apparatus for a user to generate an application with functionality beyond that of a collaborative writing tool.
Many of the features in these examples are provided through PHP: Hypertext Preprocessor (PHP). PHP is a programming language for creating web applications that execute on Wiki environment 302 . PHP is an open source, hypertext markup language embedded scripting language designed as a high-level tool for generating dynamic web content.
Depending on the particular implementation, the different features provided in the illustrative embodiments may be facilitated through the use of a virtual machine, such as a Java virtual machine (JVM). Also, other scripting languages other that JavaScript may be used to implement these processes, depending on the particular embodiment.
Turning now to FIG. 4, a diagram illustrating a Wiki architecture is depicted in accordance with an illustrative embodiment of the present invention. In these particular examples, this architecture is a quite easily done (QED) Wiki architecture. As illustrated, Wiki environment 400 contains Wiki engine 402 . This engine includes request handler 404 , command processor 406 , and page composer 408 . Request handler 404 receives requests from clients.
For example, a user may send a universal resource identifier (URI) in the form of a universal resource locator (URL) to Wiki environment 400 . This request is received by request handler 404 for processing. In these examples, one page is generated for each request handled by request handler 404 . Request handler 404 also generates “page fragments” for handling AJAX based interactions which are hypertext markup language source fragments rather than complete hypertext markup pages.
Command processor 406 processes different commands to build a page or page fragment in response to a request received by request handler 404 . Additionally, command processor 406 renders a page when processing of commands and text fragments has completed. Page composer 408 is also involved in generating the page request by the user. In these examples, page composer 408 is employed in layouts, page body content, and script collection for a page.
Wiki environment 400 also includes ancillary functions 410 . In this example, ancillary functions 410 include lists 412 , comments 414 , email 416 , and attachments 418 . With lists 412 , a user may generate lists for other users to see. Further, using comments 414 , the user may add commentary or other text to different pages. Attachments 418 allows a user to attach files to a particular page. Email 416 allows for users to be notified when pages have been updated or modified, or for a user to send an email to a page as an attachment. Email 416 also allows one or more users to receive messages regarding changes to a specified page. Users may subscribe to a rich site summary (RSS) feed of the Wiki to determine when pages of the Wiki change.
Additionally, Wiki environment 400 contains Wiki commands 420 . Wiki commands 420 within the illustrated embodiment contain two types of commands, built-in commands 422 and custom commands 424 . Built-in commands 422 are commands or services that are present within Wiki environment 400 . Custom commands 424 reference commands that are provided through external sources. Basically, these commands allow a user to include and process data for a page.
In one ore more embodiments, Wiki commands 420 involve the use of a service oriented architecture (SOA). Such SOA commands allow a user to include services with a page. In these examples, commands may reference services with well defined interfaces that are independent of the applications and the competing platforms in which they run.
In the depicted examples, services are software modules. These types of services are typically based on a standard-compliant interface, such as web service description language (WSDL). Of course, the services referenced by Wiki commands 420 may involve any type of interface. These commands may take various forms. For example, the commands may be for financial, weather, mapping, news and events, searching, government, or international information.
Database 426 , contains information, such as the pages requested and created by users. Further, revisions of pages, attachments, comments, and other information are stored within database 426 . Information is typically stored in the form of tables 428 within database 426 in the illustrative embodiments.
Turning now to FIG. 5, a diagram illustrating dataflow in rendering a page is depicted in accordance with an illustrative embodiment of the present invention. In these examples, a page is rendered on a server when processing of the page is completed and the page is ready for transmission to a client. The different components illustrated in FIG. 5 are manipulated through a Wiki engine, such as Wiki engine 402 in FIG. 4.
The programming architecture and model illustrated in these illustrative embodiments allow for visual assembly of Wiki content using a browser on a client. Everything requested by the client is conceptually a page. For example, a variable is referenced using a universal resource identifier model, such as a page and variable name. Further, pages are used as data structures in these examples. Variables are stored for later use. These variables include session variables, request variables, and persistent variables.
In the illustrative examples, users create structured data though lists. These lists may be queried, searched, and/or combined. In manipulating lists, the users employ a create, retrieve, update, and delete (CRUD) process.
Wiki controller 500 receives universal resource identifier 506 from a user. Wiki controller 500 contains router 502 and object variables 504 . Router 502 delegates request processing to the appropriate request handler. Object variables 504 provide interconnection between the processing components. For example, Wiki controller 500 has object variables 504 “Wiki” which is a pointer to Wiki object 508 . Each object in FIG. 5 has object variables that are references to other resources required for object interaction. Wiki controller 500 is handled by a request handler, such as request handler 404 in FIG. 4.
In response to receiving universal resource identifier 506 , Wiki controller 500 instantiates an instance of Wiki object 508 . As illustrated, Wiki object 508 contains object variables 510 , variables 512 , PHP security 514 , email check 516 , user 518 and page 520 . Wiki object 508 is an instance that is instantiated whenever a request is received and which acts as a repository for all of the objects used to generate content for page 520 .
In these examples, object variables 510 contains the information needed to process page 520 . Variables 512 contain session information stored in session 522 . This session information is information used during user interaction with a page or during the generation of a page in these examples. More persistent data in object variables 510 are stored in database 524 . Database 524 stores any information that may be used to generate the page or to store changes made by a user in the depicted examples.
PHP security 514 is a function used to determine whether code identified by a client may be run as well as to initiate execution of the code. PHP is an open source programming language that is mainly employed on server side applications. In these illustrative examples, PHP code may be executed by different objects within a Wiki environment. In these examples, a user may run PHP code from the client-side, as well as the server-side. Email check 516 is provided in Wiki object 508 to check for email messages that may be displayed on page 520 when page 520 is rendered and sent to a user. User 518 contains information about the user, such as user privilege levels, identifiers, and session logs.
Page 526 is a more detailed example of page 520 contained within Wiki object 508 . In this example, page 526 contains object variables 528 , attachments 530 , process 532 , access 534 , layout 536 , scripts 538 and content 540 .
In these examples, object variables 528 contain an instance of variables for page data structures. For example, a section array may be present to provide for layout information. A context pointer may reference a root Wiki command. An instance ID may be present in object variables 528 to reference an internal page ID. These different variables contain information needed to render a page, such as page 526 , to be sent to a user.
Attachments 530 are identifications of attachments that may be presented on a page. If a user selects an attachment, the attachment can then be downloaded to the user at that time. Process 532 contains the code used to generate a page to be delivered to the user. In these illustrative examples, a process is a method, for example, to identify content for the page, identify any attachments and identify any scripts that may be included in the page to be sent to the user.
Access 534 is used to determine what access privileges the user has with respect to content to be placed on the page. Such access privileges are identified in one embodiment utilizing access control lists (ACLs) 542 . Content to be included may vary for page 526 depending on the access that a particular user, requesting the page, has. This user is the user requesting page 526 . In generating content for page 526 , object variables 528 references Wiki command context 544 . This command context contains object variables 546 and content 548 . Object variables 546 represent an in-memory version of a page's contents. These variables include a list of the commands and a list of text fragments that comprise the current page. Content 548 represents the object methods used to manipulate the page content.
In executing process 532 in page 526 , a set of commands from commands 550 are identified through Wiki command context 544 . Wiki command context 544 generates a set of command instances from commands 550 . Wiki command context 544 parses content 540 and loads the commands to create a tree structure of fragments, such as fragment 552 . Fragment 552 also contains object variables 554 and content 556 . Fragment 552 is a portion of page 526 in un-rendered form. In this example, Wiki command context 544 contains fragments that represent the structure of the commands that are to be included in the page. These are commands that may be user-manipulated. When process 532 is complete, page 526 is sent down to a requesting user. Data hub 558 is saved for later use in the interaction. Also, in this example, data hub 558 is restored when a user interacts with a component within page 526 and contians processes and a data structure. The processes within data hub 558 are used to identify what commands for a page within fragment 552 are consumers of any data or commands that may be received by data hub 558 . Additionally, data hub 558 will return results to the client. These results are sent to a data hub located on the client.
Turning now to FIG. 6, a diagram illustrating components on a client and server for a Wiki application is depicted in accordance with an illustrative embodiment of the present invention. In this example, client environment 600 is a more detailed illustration of client environment 300 in FIG. 3. Client environment 600 in these illustrative embodiments may take the form of a client web browser or some other application that has connectivity to a network, such as the Internet. Wiki environment 601 executes on a data processing system, such as server 104 in FIG. 1.
In this example, client environment 600 receives page 602 . Page 602 includes a plurality of components, such as header 604 , footer 606 , left margin 608 , right margin 610 , menu 612 , and body 614 . Header 604 , footer, 606 , left margin 608 , and right margin 610 are page components for laying out pages. These components include various content, such as hypertext markup language (HTML) content.
Menu 612 provides access to actions or functions that a user can perform on page 602 or in conjunction with page 602 . For example, menu 612 can include a menu item to send a request to the server that, when granted, would permit the user to edit page content in a WYSIWYG editor.
In this example, different types of content are found within body 614 . In this example, body 614 contains HTML content 616 , date information 618 , and variable 620 . Body 614 also contains commands 622 , 624 , 626 , 628 , 630 , and 632 . Commands 622 , 624 , 626 , 628 , 630 , and 632 are Wiki commands, such as Wiki commands 420 in FIG. 4. These commands are commands for a Wiki application presented though page 602 . Commands 622 , 624 , 626 , 628 , 630 , and 632 along with data hub 634 provide for dynamic content within page 602 .
Data hub 634 is a data hub object in a Wiki environment, similar to data hub 558 in FIG. 5. However, data hub 634 is a client-side data hub. Data hub 634 includes attributes and a set of methods for sending and receiving event objects between the commands in page 602 and those in Wiki environment 601 . Data hub 634 includes attributes and a set of methods for sending and receiving events and/or data between the commands in page 602 and those within Wiki environment 601 .
An event object is a data object that defines an event that is transmitted between commands associated with a Wiki page, such as page 602 . An event object can include, but is not required to include, event data. In these examples, an event is a message indicating that something has happened, such as an occurrence or happening of significance to a task, program, or command. For example, an event can include receiving user input, gathering a minimum required set of arguments, completion of a command operation, a given time occurring, or any other activity, receipt of input or data, occurrence, happening, or activity.
The illustration of the different types of content within page 602 is presented for purposes of depicting the manner in which a Wiki application may be presented to a user. This illustration, however, is not meant to imply limitations as to the type and scope of content that may be used in a Wiki application. For example, page 602 may include other additional content, commands, and/or components not illustrated in FIG. 6 without departing from the scope of the illustrative embodiments of the present invention.
A user may manipulate content within page 602 to use the Wiki application and/or change the manner in which the Wiki application performs. In other words, the user may add content or remove content, such as commands, from page 602 though manipulating a graphical representation of these commands to generate or modify content and/or functionality for page 602 .
In this example, Wiki environment 601 is a Wiki environment, such as Wiki environment 302 in FIG. 3 and Wiki environment 400 in FIG. 4. Wiki environment 601 includes commands 640 - 650 in the form of command trees or abstract syntax trees. Commands 640 - 650 are updated in the Wiki environment. Commands 640 - 650 and commands 624 - 632 differ in implementation but refer to similar command. For example, command 632 is associated with a client environment and is updated in client environment 600 by a user. Corresponding command 650 is updated in Wiki environment 601 by means of asynchronous JavaScript and extensible markup language using AJAX 636 over a network connection.
AJAX 636 is a web development technique for creating interactive web applications, such as Wiki pages. AJAX 636 exchanges small amounts of data with an associated host server behind the scenes so that an entire page is not reloaded each time a user makes a change to a requested page. AJAX 636 is meant to increase the interactivity, speed, responsiveness, and usability of a page, such as page 602 . Although the illustrative embodiments depict exchanging data via AJAX or JSON, any communication protocol agreed upon between a given set of components may be used to exchange data in accordance with the illustrative embodiments of the present invention.
Commands 640 , 642 , 644 , 646 , 648 , and 650 in Wiki environment 601 interact with data hub 638 . Data hub 638 is a server-side data hub, such as data hub 558 in FIG. 5. In this illustrative example, data hub 634 of client environment 600 and data hub 638 exchange events and/or data via AJAX 640 . AJAX 636 and 640 may communicate using extensible markup language (XML) as the format for transferring data between client environment 600 and Wiki environment 601 , although any format will work, including preformatted hypertext mark-up language (HTML), plain text, and JavaScript object notation (JSON). JavaScript object notation is a lightweight computer data interchange format. JSON is a subset of the object literal notation of JavaScript but its use does not require JavaScript.
The illustrative embodiments provide a computer implemented method, apparatus, and computer usable program code for an application Wiki. A Wiki application is a collaborative web environment that allows single or multiple users to efficiently integrate static and interactive content. A Wiki page is a page within the Wiki application. The illustrative embodiments of the present invention allow a user to easily create and manage Wiki pages. The user may edit a Wiki page by dragging and dropping live content. Live content is dynamic content that is being updated based on changing information. For example, live content may include a weather graphic for a specified geographic location that is updated by a server linked to a weather radar station.
Wiki pages are saved in a page tree view. The page tree view is a content hierarchy that includes pages and sub-pages. The page tree view may be referred to as a Wikispace, page space, tree, or other content hierarchy. Each page within the present description may be both a content provider and container for other sub-pages as required. The page tree view differs from other file structures because all of the pages may include content and simultaneously be viewed as containers. The pages in the page tree view are distinguished by the name assigned to each page. The pages include nodes and leaf nodes. Nodes may display content and function as folders or containers for other Wiki pages. Leaf nodes strictly provide content.
Turning now to FIG. 7, an exemplary screen of display for dragging live content is depicted in accordance with an illustrative embodiment of the present invention. Wiki page 700 is a page, such as page 602 in FIG. 6. Wiki page 700 may be specifically edited in a design mode. For example, a user may check a quite easily done (QED) check box indicating that the Wiki page is being edited. In design mode, Wiki page 700 may display palette 702 . Palette 702 is a toolbar or a set of tools used to collaboratively manipulate a web page. For example, the user may use palette 702 to select live content for display in body 704 of Wiki page 700 . Body 704 is the portion of Wiki page 700 that may be customized and edited to display user-specified content.
Palette 702 may include any number of icons 706 , 708 , and 710 . Each icon is a graphical representation of an available command. Palette 702 may be used to display content which may include commands, data, page content, Wiki utilities, data services, customized lists, and any number of other features.
Icon 706 may be, for example, a live link to a Google™ search tool in the form of an icon. Icon 708 may be a live link to Google™ maps (Google, Google Search, and Google Maps are trademarks of Google Corporation in the United States, other countries, or both). Icon 710 may be a rich site summary or really simple syndication (RSS) feed. Rich site summary is a protocol and application of extensible markup language (XML) that provides an open method of syndicating and aggregating web content. Using rich site summary, a user may create a data feed that supplies headlines, links, and article summaries from a web site. Users may have constantly updated content from web sites delivered to Wiki page 700 via a news aggregator in body 704 . A news aggregator is a piece of software specifically tailored to receive these types of feeds.
In one example, a user may display a Google® map in body 704 by dragging icon 708 from palette 702 onto body 704 . The user may further customize the content displayed by a Wiki command using a property editor as will be described in FIG. 8. Existing Wiki commands in the page content display eye-catchers, such as eyecatcher 712 , that indicate properties of the existing Wiki command may be edited.
Turning now to FIG. 8, a screen of display for editing properties of a command is shown in accordance with an illustrative embodiment of the present invention. A modern application Wiki needs a visual means of editing Wiki “markdown” command attributes that does not require the user to edit the page, allowing the user to modify command settings without a jarring page refresh and conceptual context switch.
An application Wiki reduces the burden of a user having to know or learn hypertext markup language markup. In these examples, an application Wiki introduces shorthand syntax for creating lists and tables and other hypertext markup language constructs which uses a combination of short character sequences, line position, and white space. For example, a list item is defined by a single asterisk (*) in the first column of a line, followed by a single space versus the <OL><LI></LI></OL> tags required in hypertext markup language. The shorthand syntax introduced by the application Wiki is called “markdown” to emphasize the difference between creating content with hypertext markup language and in a Wiki environment. Wiki command classes support the generation of a visual property editor for editing “markdown” commands.
Wiki page 800 is a partial view of a Wiki page, such as Wiki page 700 in FIG. 7. Palette 802 is similar to palette 702 in FIG. 7. Wiki page 800 contains Wiki commands which display eye-catchers 804 and 806 , named stores and list.
Properties of Wiki commands displaying eye-catchers 804 and 806 may be edited using property editor 808 . Properties are the attributes, data, fields and other information used by the command represented by the eye-catcher to display content on Wiki page 700 in FIG. 7. Property editor 808 allows a user to customize the information displayed by the live content. Property editor 808 is comprised of hypertext markup language and JavaScript which is downloaded, along with Wiki page content to the browser client. For example, a user may specify a specific address for displaying a Google® map. Similarly, the user may make queries and limit the information displayed in Wiki page 800 .
The user may use property editor 808 to enter width and height values for Wiki commands that allow their visual representation to be sized. Additionally, property editor 808 may be used to enter scaling factors, names of data sources, and maximum and minimum values are some other examples. Property editor 808 is used to surface points of variability of a Wiki command to the user.
For example, process 532 in FIG. 5 may generate a default property editor for each command as necessary. Each Wiki command may contribute a custom property editor to surface the unique points of variability for the Wiki command. Selecting eye-catchers 804 or 806 for a command causes the property editor for the associated command to be displayed.
Turning now to FIG. 9, a page tree view is depicted in accordance with an illustrative embodiment of the present invention. Page tree view 900 is a visual storage structure for visually displaying the organization of Wiki pages to a user. Page tree view 900 shows the names or tags of Wiki pages within the Wiki application. Tags are user-assigned labels that are used to categorize content of a Wiki. Each page in these examples is a node or leaf node.
Wikispace 902 is the base page of page tree view 900 and may also be used to refer to the content of page tree view 900 . Page tree view 900 is different from other file systems and data structures because Wikispace 902 and the other base pages or nodes including test 904 , testing 906 , toplevel 908 , and Wiki 910 may both display content and function as folders or containers for other Wiki pages. A graphical indicator, such as a “+” sign, may indicate a Wiki page is a node. Wikispace 902 uses a flat hierarchy where each page represented by a node may be a container and content provider. For example, Wikispace 902 includes content but may also be used to link to Wiki sub-pages or leaf nodes including helloworld 912 , homepage 914 , and menutest 916 . The base pages in page tree view 900 may be displayed as both content providers and page containers in these examples.
The user may use page tree view 900 to navigate the Wiki pages. For example, by clicking on a Wiki page, the contents and/or sub-pages of the Wiki page are displayed. As a result, the user may easily navigate the Wiki by selecting the page name.
Turning now to FIG. 10, a screen of display for a Wiki page is shown in accordance with an illustrative embodiment of the present invention. Wiki page 1000 is a page, such as Wiki page 602 in FIG. 6. A user may have used an eye-catcher in a palette, such as eye-catcher 708 and palette 702 in FIG. 7 to drag live content into Wiki page 1000 .
For example, a business traveler may have previously modified Wiki page 1000 to display list of destinations 1002 for an upcoming business trip. By clicking on each location within list of destinations 1002 , the Wiki page displays national map 1004 for the address, weather forecast 1006 , as well as local alerts 1008 . The customized information allows the user to plan for weather and other circumstances of the business trip as well as visually picture the location of each meeting. Local alerts 1008 may include links to ongoing events and new stores for the specified geographic location, informing the user of local events that may be relevant to the business meeting.
The illustrative embodiments further provide a computer implemented method, apparatus, and computer usable program code for processing a web page for display in a Wiki environment. Added components are able to interact with other components before rendering the final views. Components are enabled to discover new attributes and parameter settings from the page serve context. A validation mechanism is used for components to validate inputs and report errors before rendering final views. Targeted events are processed within the lifecycle of the page serve sequence. Multiple versions of the same component are managed on a single server.
Turning now to FIG. 11, a block diagram of an abstract syntax tree is shown in accordance with an illustrative embodiment of the present invention. Abstract syntax tree environment 1100 includes various components used to form and process abstract syntax tree 1102 .
Wiki command context (WCC) 1104 is an object that creates abstract syntax tree 1102 from the markup language of a Wiki page, such as page 602 in FIG. 6. Wiki command context 1104 is the parent of the abstract syntax tree of commands. Wiki command context 1104 is responsible for loading the commands for a page or source fragment. Abstract syntax tree 1102 is composed of commands, such as commands 640 , 642 , 644 , 646 , 648 , and 650 in FIG. 6 for the Wiki source. A tree is a data structure including a source or base branching out to include leafs or nodes. The interconnecting nodes in the tree represent commands that are dependent on other interconnected nodes. Nodes, such as nodes 1106 - 1110 , represent different commands in abstract syntax tree 1102 .
For example, node 1106 is named Accordion and performs the step necessary to internalize the attributes and variables assigned by the user to the accordion and emit the hypertext markup language fragment for the accordion targeting the client browser environment. Node 1108 is named Template and is a child of node 1106 , named Accordion. Node 1106 provides the name of a tab within the Accordion to display on the client browser environment. Node 1110 is named Forecast and is a command for inserting a weather forecast in the Wiki page.
Data hub 1112 is a data hub, such as data hub 638 in FIG. 6. Data hub 1112 processes abstract syntax tree 1102 by walking abstract syntax tree 1102 in a pre-order traversal and invoking the particular function at each node. For example, node 1114 has a function for providing a latitude and longitude. Node 1114 may be a Google® map command that provides the latitude and longitude for a specified address.
Depending upon the complexity of the page, abstract syntax tree 1102 represented by Wiki command context (WCC) 1104 may contain two types of child nodes: first, those previously described and second, other abstract syntax trees whose root is another Wiki command context. Another Wiki command context is used when processing uniform resource indicator requests that generate other Wiki source fragments that also need to be processed.
The illustrative embodiments of the present invention further provide a computer implemented method, apparatus, and computer usable program code for extending the capabilities of a Wiki environment. A Wiki is a collaborative web page that allows single or multiple users to efficiently integrate static and interactive content. An object-oriented framework is used to define how objects are extended for easily creating collaborative environments. Wiki environments need to support a fundamental mechanism to extend the core environment without requiring changes to the core runtime components.
The illustrative embodiments include client and server side elements that process the Wiki commands to manage a deployed environment including any number of Wiki commands. An abstract set of base classes and a core processing engine within the Wiki environment is used for processing concrete implementations of the Wiki command classes as further described. The core processing engine supports the processing and lifecycle management of the core runtime components for extending the capabilities of the Wiki environment. The core processing engine is an engine, such as Wiki engine 402 in FIG. 4.
Turning now to FIG. 12, a block diagram of commands is depicted in accordance with an illustrative embodiment of the present invention. Wiki commands are commands used to implement the functions and processes of the Wiki, such as Wiki environment 302 in FIG. 3. FIG. 12 describes a Wiki command metadata interface and associated commands 1200 . Commands 1200 are commands, such as command 550 in FIG. 5.
Commands 1200 include various command categories which may include catalog 1202 , lifecycle 1204 , property edit 1206 , and page processing 1208 . Only a few examples are shown in commands 1200 . For example, commands include Get/setCategory 1210 , getName 1212 , and getDescription 1214 . Get/setCategory 1210 describes the category the Wiki command belongs to. getName 1212 is the simplified name of the component. getDescription 1214 is the textual description of the Wiki command intended to help the user understand the command.
Catalog 1202 may also include other commands such as:
getHelp is help text presented when the user hovers over the Wiki command in the page or palette,
getsample returns a sample Wiki command source used to insert the command,
getIcon returns the icons to be displayed for the Wiki command in the palette,
getDragContent returns the Wiki source fragment used during the initial drag off the palette for the Wiki command, and
getDropContent returns the Wiki source fragment inserted when the Wiki command is dropped on the initial placement.
LifeCycle 1204 may include commands, such as wasSaved 1216 , wasDeleted 1218 , and wasCopied 1220 . wasSaved 1216 is called after the command was saved in the server environment. In these examples, wasDeleted 1218 is called when the command has been removed from the server page environment. wasDeleted 1218 provides a means for Wiki commands to clean up persistent resources associated with the Wiki command on the given page. wasCopied 1220 is called when a page containing a given Wiki command has been copied to another name. wasCopied 1220 provides a means for Wiki commands to apply any persistent changes necessary on the newly copied page.
Lifecycle 1204 may also include other commands such as:
getVersion returns the version of the Wiki command,
getParameters returns the list of parameters associated with the Wiki command,
aboutToSave is called when the command is about to be saved to the server environment, providing the command an opportunity to carry out any activities necessary to persist the command,
configure is called when the command needs to be configured,
get/setPluginData saves/gets data associated with the Wiki command during the configure command,
wasUndelete is called when the command has been placed back on a given page after previously being deleted from the page,
wasRenamed is called when the page containing the Wiki command has been renamed,
aboutToExport is called just before the Wiki command is exported to the saved format of the Wiki, and
wasImported is called just after the Wiki command is imported from the Wiki save format.
Property edit 1206 may include commands, such as generatePropertyEditor 1222 and allowEdit 1224 . In the illustrative embodiment, generatePropertyEditor 1222 is called by the core engine to permit the command to generate a client side editing visual. If generatePropertyEditor 1222 is not implemented, a default property editor is generated for editing the Wiki command's parameters. A property editor is an interface that allows a user to enter parameters, values, text, variables, and other data for the Wiki command. allowEdit 1224 determines if the Wiki command is permitted to be edited.
Page processing 1208 may include commands, such as render 1226 , drawEyeCatcher 1228 , refreshOnUpdate 1230 , and getTargetDIV 1232 . render 1226 is called when the Wiki command needs to display itself in the output stream for hypertext markup language. drawEyeCatcher 1228 is called when the command is drawn on the page to provide the content which can be clicked to manipulate the Wiki command on the client, usually invoking the property editor on the selected command. The eye catchers are used to track a singleton editing capability. refreshOnUpdate 1230 is called to determine if the whole page should be refreshed after the command's arguments have been updated using the property editor. getTargetDIV 1232 returns the name of the hypertext markup language DIV to be updated. DIV represents a division/section in a hypertext markup language file. Each command is displayed within a DIV on the client browser. A DIV has an associated identification which the Wiki engine will generate automatically or the command may provide one by implementing the getTargetDIV protocol.
Page processing 1208 may also include other commands such as:
getDestinationDiv returns the name identification of the hypertext markup language/DIV to be updated when the command is re-rendered on the page. Rendering a command is reproducing or displaying encoded data in a specified manner. For example, the eye-catcher is rendered by generating the hypertext markup language rendered in the Wiki page to display the eye-catcher.
getArguments returns the list of actual arguments passed to the command for processing. Arguments contain the ‘real’ values of the parameters returned by the getParameters call, which returns the formal argument list of the command.
refreshOnInsert is called to determine if the whole page should be refreshed after the command has been placed on the Wiki page.
areArgumentsSet returns a value specifying whether all the input arguments for the Wiki command have been satisfied so that the command may ‘fire’ its invoke method to performs model actions.
init is called to initialize the internal Wiki command.
The methods and commands described above are used to provide the processes in FIGS. 31-43.
Turning now to FIG. 13, a diagram showing property editing components is depicted in accordance with an illustrative embodiment of the present invention. Property editing system 1300 includes eye-catcher 1302 , property editor 1304 , and selector editor 1306 .
Eye-catcher 1302 is a graphical representation of a selected command. For example, eye-catcher 1302 may represent a Google™ Map command for displaying a map of a specified address. Eye-catcher 1302 may be clicked on in an icon form to invoke property editor 1304 allowing a user to edit a selected command.
Property editor 1304 is used to establish attributes of the command. For example, the attributes may specify the type of information, properties, parameters, binding information for the attribute, and default and allowable values. For example, property editor 1304 may allow a user to specify an address for the Google™ Map to generate the requested map. Selector editor 1306 is a specialized property editor that allows a user to establish specific attribute metadata. For example, a user may be able to specify an editing address using selector editor 1306 . While establishing attributes in property editor 1304 a specific attribute may automatically open selector editor 1306 to enter more specific information for an attribute or field in property editor 1304 .
The illustrative embodiments of the present invention further provide a computer implemented method, apparatus, and computer usable program code for processing a request for a Wiki page received from a client-side data hub on a remote data processing system at a server-side data hub. A server-side data hub is a data hub object instance on the server that is instantiated when the page request is received by the server. The server-side data hub is associated with a particular page instance. Thus, each time the server receives a request from the client associated with the page, such as to modify or update the page, the instance of the server-side data hub associated with the particular page can be retrieved and loaded to process the request.
The server-side data hub includes attributes and a set of methods. This set of methods is one or more methods on the data hub, which are used to send events from a producer command on the server to a set of consumer commands associated with the instance of the collaborative application. The set of consumer commands may be located either on the server-side, on the client-side, or both in these examples.
A consumer command is a command that needs to receive or wants to receive an event and/or data for processing and/or performing a function of the command. A consumer command registers with the data hub to receive event objects associated with a given topic.
For example, a search component needs or wants to receive search input terms to perform the search-function of the search component. Therefore, the search component is a consumer of search input terms. The search command is therefore a consumer of events related to search terms and available topics.
A consumer command can also be referred to as a listener command because the consumer command is listening or waiting for events related to one or more specific topics. In the above example, the search component is listening for topics related to available search terms.
In these examples, a set of consumers includes a single consumer as well as two or more consumers.
The client-side data hub is created at the client when the requested page is received at the client. This client-side data hub is associated with an instance of a collaborative application, such as a Wiki application.
The utilization of server-side data hub and a corresponding client-side data hub enable the Wiki commands associated with the requested page to interact with greater ease during processing of the page request by routing events transmitted between commands through the server-side data hub and/or the client-side data hub.
In accordance with the illustrative embodiments of the present invention, a server-side data hub and/or a client-side data hub can be utilized to route events between commands in any application using an eventing mechanism. An eventing mechanism is a mechanism that permits modules in an application, such as Wiki commands, to communicate with other modules in the application. For example, a web browser uses an eventing mechanism. In addition, web applications, such as email components and newsreaders, also utilize an eventing mechanism.
Turning now to FIG. 14, a diagram illustrating a data flow between commands on a client and server for a Wiki application is depicted in accordance with an illustrative embodiment of the present invention. Server 1400 is a server, such as server 104 and 106 in FIG. 1. Server 1400 is part of a Wiki environment, such as Wiki environment 302 in FIG. 3, Wiki environment 400 in FIG. 4, and Wiki environment 601 in FIG. 6.
Data hub 1402 is a server-side data hub, such as data hub 558 in FIG. 5 and data hub 638 in FIG. 6. Data hub 1402 is created on server 1400 when a request for a page is received from client 1408 . Thus, server-side data hub 1402 is instantiated upon receiving a request from a client-side data hub. Server-side data hub 1402 is an instance of a data hub object having attributes and methods to propagate or route events between commands in the Wiki environment. The set of methods on server-side data hub 1402 are used to process events and commands associated with the page request received from the user on client 1408 .
Wiki command 1404 is a Wiki command object present within the Wiki system, such as commands 422 in FIG. 4, command 550 in FIG. 5, and commands 640 - 650 in FIG. 6. Wiki command 1404 allows a user to include data in a page and/or process data for a page, or any other functionality associated with the requested Wiki page. In this example, Wiki command 1404 is processed by a page process loop of a Wiki page object, such as Wiki page object 526 in FIG. 5.
Data hub 1402 determines if all the required data and/or input values required by the argument parameters of Wiki command 1404 are present. If all the required data and/or input values are present, data hub 1402 triggers an invoke method on Wiki command 1404 . The invoke method triggers Wiki command 1404 to fire event 1406 to server-side data hub 1402 . Event 1406 is an event object defining an event.
In this illustrative example, event 1406 is fired by Wiki command 1404 on server 1400 . However, in accordance with the illustrative embodiments of the present invention, event 1406 can also include an event received by server-side data hub 1402 from client-side data hub 1410 . In such a case, event 1406 would be an event fired by a command on the client, such as event 1407 , which is an event object fired by client-side Wiki command 1412 . In accordance with another illustrative example, event 1407 can include an event generated by client-side Wiki command 1412 and sent to client-side data hub 1410 for processing on the client or routing to server-side data hub for processing on server 1400 .
Upon receiving event 1406 from Wiki command 1404 , data hub 1402 sends event 1406 to an event queue for processing. An event queue is a buffer or data structure for storing event objects until the event object is processed.
During a process events phase, server-side data hub 1402 processes event 1406 . During the processing of event 1406 , server-side data hub 1402 determines if any commands, such as Wiki command 1404 , are registered as consumer commands of event 1406 . A consumer command is a command that requires an event associated with a given event topic. An event topic is a subject matter or theme associated with an event object. For example, an event object fired as a result of a user entering a search term would have a “search” or “search available” event topic.
The consumer command registers with a data hub as a consumer command for the given topic. Thus, when an event object for the given topic is received by the data hub, the data hub is able to send the event to the set of registered consumer commands for the given event topic.
A registered consumer command is a command that has registered as a consumer of events of a given topic. For example, a display command aggregates sets of data for a topic such as accident. This command reports to display on a map display, will register with the data hub as a consumer command for the topic accidents. When the data hub receives an event for accidents, the accidents event object will be sent to all consumer commands registered for the topic accidents, including the display command. Once the display command receives the accidents topic event, the display command will consume or use the data to generate a map display showing the accident data or update a previously displayed map to show the new accident data.
Data hub 1410 sends event 1406 to Wiki command 1412 for processing. Data hub 1410 determines if all of the required data and/or input values for a given argument/parameter required by Wiki command 1412 to fire are present in Wiki command 1412 . If all of the required data and/or input values are present, data hub 1410 triggers an invoke method on Wiki command 1412 . In response to data hub 1410 calling the invoke method on Wiki command 1412 , Wiki command 1412 sends or fires event 1407 to data hub 1410 for processing. When event 1407 is completely processed, data hub 1410 will send event 1406 to a browser or client for display. An event is completely processed when the event is in a proper format for display at a browser, such as hypertext markup language code.
Thus, the illustrative embodiments provide a computer implemented method, apparatus, and computer usable program code to process a request for a page. A server-side data hub receives the request for the page from a client-side data hub on a remote data processing system. The client-side data hub is associated with an instance of a collaborative application. The server-side data hub processes the request during the initial page render process using a set of methods. The set of methods is used to send events from a producer command on a server to a set of consumer commands associated with the collaborative application.
Turning now to FIG. 15, a diagram illustrating a data flow between commands on a server during an initial page render process is depicted in accordance with an illustrative embodiment of the present invention. Data hub 1500 is a server-side data hub, such as data hub 558 in FIG. 5 and data hub 638 in FIG. 6. In this illustrative example, data hub 1500 is implemented in PHP: Hypertext Preprocessor (PHP). Wiki command producer 1502 is a command associated with the server. A producer is a Wiki command component that provides data that can be used or consumed by another Wiki component. In this illustrative example, Wiki command producer 1502 registers as a producer of an event for the topic “cars”. To register Wiki command producer 1502 as a producer of topic “cars,” data hub 1500 adds an identifier for Wiki command producer 1502 to an object variable for producer identifiers associated with the topic “cars.”
Wiki command consumer 1506 is a command associated with the server. Wiki command consumer 1506 registers as a consumer for topic “cars” 1508 with data hub 1500 . To register Wiki command consumer 1506 as a consumer of topic “cars,” data hub 1500 adds an identifier for Wiki command consumer 1506 to an array of consumer command identifiers in a consumer object variable on data hub 1500 .
Wiki page 1510 is an object having a process loop associated with a given requested page being loaded in the Wiki environment. During the init phase, the server calls an init method to initialize all commands associated with the given requested page, such as Wiki command producer 1502 . Upon initialization, the commands register with the data hub as producer commands, such as Wiki command producer 1504 , or consumer commands, such as Wiki command consumer 1506 .
Wiki command producer 1502 retrieves data and fires an event with the topic “cars/available” when WikiCommand producer 1502 has data and/or an event ready to fire. When Wiki command producer 1502 fires the event topic “cars/available” event 1512 , the event is sent to data hub 1500 . Data hub 1500 adds the topic “cars/available” event to an event queue 1514 in data hub 1500 . After processing the topic “cars/available” event from the event queue, the topic “cars/available” event is sent to all consumers that registered for the event topic “cars.”
The Wiki page process loop of the Wiki page object calls the first processEvents method. During this process events phase, the data hub processes events in the event queue on server-side data hub, including the “cars/available” event object fired by Wiki command producer 1502 . Data hub 1500 retrieves event “cars/available” from the event queue. Data hub 1500 calls a callback method on each command registered as a consumer for the event topic “cars” 1518 , including Wiki command consumer 1506 . The event is passed to Wiki command consumer 1506 as an argument/parameter to the callback method. The consumer callback method processes the event object by executing code inside the callback method.
If additional processing is present to be performed after initializing all components, but before rendering the requested page, each command has an opportunity to execute code by calling a discover method. The second processEvents phase 1520 is called to process any events that may have fired during the discover phase.
Finally, Wiki page object 1510 calls the render phase on all commands. During the render phase, all commands should have all of their data available so that the hypertext markup language code can be generated and sent to the client for rendering as the requested page at a client browser. If WikiConsumer 1506 is a table display of “cars” data generated by producer, the render phase could generate a table of cars as shown in FIG. 16.
Referring now to FIG. 16, a diagram illustrating Wiki page 1600 generated in response to a page request from a user is shown in accordance with an illustrative embodiment of the present invention. As discussed above, all commands associated with a page can register as producers and consumers with a data hub. As events are produced by the producers, the events are used by the consumers to render hypertext markup language or JavaScript for rendering an entire page or page fragments. The hypertext markup language or JavaScript is sent to the client browser for display.
Thus, all interactions ripple through the data hub during a Wiki page process loop. As a result of these interactions, all events are handled at render time. Therefore, the initial rendered page, such as page 1600 , fully depicts the correct view of the Wiki page. In other words, the client does not have to fire events to modify the initial rendered page to make the page view correct because all events associated with loading a new page from the server are processed through the server-side data hub.
When an initial request for a page is processed at a server, the server generates hypertext markup language code and/or JavaScript for the requested page. When the hypertext markup language code and/or JavaScript is received at the client, the new page is loaded at the client for display in the client browser.
During the page load process, the hypertext markup language code and/or JavaScript code for the page creates a client-side data hub object. The client-side data hub object registers all commands on the client with the client-side data hub as producer commands and consumer commands, just as the commands on the server registered with the server-side data hub during the initial page process loop at the server.
If a command interaction occurring at the client after the initial page is loaded can be completely contained and processed on the client, the command interaction is not sent to the server in these examples. In other words, Wiki commands interact on the client to modify the displayed page to reflect additional input or events triggered by user actions or other occurrences at the client. If a component interaction can be completely processed on the client, the client generated event is not sent to the server. This event may be capable of processing entirely at the client. If this is the case, then the server does not have to be involved in the processing of the event in any way. In the depicted embodiments, the term modify includes updating a page or otherwise altering a page to reflect new data and/or new page content.
Thus, the illustrative embodiments of the present invention provide a computer implemented method, apparatus, and computer usable program code for a client-side data hub for processing events. The client-side data hub receives an event for a given topic. The event is generated by a producer command associated with the client. The client-side data hub processes the event to identify a set of consumer commands for the given topic. The client-side data hub sends the event to a set of consumers for the given topic. The client-side data hub receives new page content from one or more consumers in the set of consumers, wherein the displayed page is updated with the new page content to form an updated page.
Turning now to FIG. 17, a diagram illustrating a rendered page displayed at a client browser is depicted in accordance with an illustrative embodiment of the present invention. On rendered page 1700 , search input from component 1702 has registered as a producer of the event topic “search/available” with the client-side data hub. An echo consumer component 1704 has registered as a consumer of the topic event “search/available” with the client-side data hub. Consumer component 1704 functions to echo what a user types into search component 1702 when the search component fires a “search/available” event.
FIG. 18 is a diagram illustrating a data flow between components on a client-side data hub after a new page is loaded and displayed at a client browser in accordance with an illustrative embodiment of the present invention. Data hub 1800 is a client-side data hub, such as data hub 634 in FIG. 6, and data hub 1410 in FIG. 14. Data hub 1800 is created on the client during a page load. In this illustrative example, client-side data hub 1800 is implemented in JavaScript and hypertext markup language.
Wiki command producer 1802 is a command on the client that provides data that can be consumed by another Wiki command or wants to notify another component that a particular event has occurred. Wiki command producer 1802 registers 1804 with data hub 1800 as a producer for the topic “search/available.” In this example, Wiki command producer 1802 is search component 1702 in FIG. 17.
Wiki command consumer 1806 is a command on the client that consumes an event object, consumes data, or wants to be notified of an event. Wiki command consumer 1806 registers as a consumer for the event topic “search/available” 1808 with client-side data hub 1800 . In this example, Wiki command consumer 1806 is echo consumer component 1704 in FIG. 17. Wiki command consumer 1806 is a client version of a corresponding Wiki command object on the server. Wiki command consumer 1806 on the client includes all the data of the Wiki command object on the server, but it does not contain all of the methods found in the corresponding Wiki command on the server.
Wiki command producer 1802 fires the “search/available” event when a user presses the “go” button after entering a search term, such as “Wiki” search term shown in FIG. 17. Wiki command producer 1802 creates an event object, attaches data to the event object, then fires the event object by calling a fireEvent method 1810 on data hub 1800 to send the event to data hub 1800 . Unlike the server-side data hub which queues events at the data hub and processes the events during a processEvents phase, client-side data hub 1800 does not send the event to an event queue. Instead, client-side data hub 1800 immediately processes the event and sends the event to a set of consumers registered for the event.
In this illustrative example, the echo component callback 1812 is called by data hub 1800 . Wiki command consumer 1806 modifies the rendered page, such as page 1700 in FIG. 17, using JavaScript to insert the text “Search term: Wiki” into the displayed page. An exemplary illustration of JavaScript used to dynamically update the content of the rendered page by Wiki command consumer 1806 includes as follows:
| var divId = document.getElementById(‘echoDivId’); | |
| divId.innerHTML = “Search term: | |
| ”+event.getValue( ); | |
However, in accordance with an illustrative embodiment of the present invention, the rendered page can be modified by Wiki command consumer 1806 using any known or available method for modifying a page, including, but not limited to, document object model (DOM) manipulation.
However, if the interaction requires the server to be involved in the processing of the event, the event is sent to the server. It is likely that an event fired on the client will require the event to be sent to the server data hub, because the data either lives on the server or is retrieved by the server.
In other words, after a page is displayed at the client, a new event or new data is received from a user. This event may require processing in whole or in part at the server. If this is the case, then the client sends the event to the server prior to updating the displayed page.
Data hub objects on the client and server enable Wiki components and commands to interact on the client, interact on the server, and use topic based eventing mechanisms to effectively wire/connect the components. When the result of a user interaction requires the server to be accessed to perform some operation or process not possible on the client, the client-side data hub sends the event to the server-side data hub.
For example, if the server owns or has access to data required for a given user interaction, such as a database table, that the client does not own or have access to, the event is sent to the server. In addition, if the server is needed to retrieve data needed for a user interaction, such as a data feed, the event is sent to the server. In these cases, the event is sent to the server for handling/processing. Once handling/processing of the event on the server is complete, the server sends updated page content to the client for modifying the displayed page at the client.
For example, a search component is a component that accepts input from a user. Based upon the text entered by the user, the search text is sent to the server. The server performs the search. The server renders the results of the search using a table component. The rendered table generated by the table component on the server is returned to the client for display.
The illustrative embodiment of the present invention also provide a computer implemented method, apparatus, and computer usable program code for data hub processing of events. A client-side data hub receives an event for a given topic associated with a currently displayed page. The client-side data hub sends the event data to a server-side data hub for processing of the event on the server.
The server-side data hub adds an event for the given topic to an event queue on the server-side data hub in response to receiving an event associated with a page. The server-side data hub processes the event in the event queue. A set of consumer commands for a given topic associated with the event are identified. A consumer command is a command that receives events for a given topic. The server-side data hub sends the event to the set of consumer commands for the given topic. One or more consumers in the set of consumer commands process the event to render page content for the page. The server-side data hub then sends the results of processing the event back to the client-side data hub.
The client-side data hub receives the results of event processing from the server-side data hub. The result of processing the event includes new page content. The currently displayed page is updated with the new page content at the client browser to form an updated page.
With reference next to FIGS. 19A and 19B a diagram illustrating a data flow between a client-side data hub and a server-side data hub during a page update is shown in accordance with an illustrative embodiment of the present invention. When the Wiki page is first loaded, the server-side commands are processed to generate the initial page render that is sent to the client for display to the user, as shown in FIGS. 8-9. In this illustrative example, server-side data hub 1900 is created when the page is first loaded. Wiki command producer 1902 is a search component.
During the init phase, Wiki command producer 1902 initializes and registers 1904 with data hub 1900 as a producer of event topic “search/available” and “search/clicked.” Wiki command producer 1902 search component also registers as a consumer for “search/clicked” event topic, which is generated by the client. In this manner, client representation of the Wiki component can communicate with the server-side component or call a method on the server-side component.
Wiki command consumer 1906 is a list component. Wiki command consumer 1906 initializes and registers 1908 with data hub 1900 as a consumer of the “search/available” event topic. The processEvents method is called on the server-side data hub during the first processEvents phase. Data hub 1900 calls the invoke method on Wiki command producer 1902 . In response, Wiki command producer 1902 performs a search and generates data which is included in a “search/available” event object. Wiki command producer 1902 fires the event object “search/available” to indicate that the search data is ready.
Data hub 1900 calls a callback method on Wiki command consumer 1906 list component to send the “search/available” event object to Wiki command consumer 1906 . The discover and secondary processEvents phase are then performed. Finally, during the render phase, data hub 1900 calls render on all commands associated with the requested page. Wiki command producer 1902 renders the hypertext markup language and JavaScript to display the search form. Wiki command consumer 1906 list component, which is now a producer component, renders the hypertext markup language and JavaScript to display the table. The results of the rendered components are combined with the rest of the hypertext markup language page and sent to the client for display. While the page is being loaded by the browser, the JavaScript code creates client-side data hub 1910 and registers all producers 1912 and all consumers 1914 with client-side data hub 1910 . This is the initial page render.
Once the page has been initially displayed, a user interaction may cause changes to the rendering of one or more components. For example, when a user enters a search term and presses “go”, a user interaction changing data occurs. The client-side search component Wiki command producer 1916 fires an event with topic “search/clicked” 1918 . The search phrase is attached to the event object as data. Client-side data hub 1910 receives the event object and sends it to any listeners on the client registered as consumers for the event topic “search.” Unlike in the server-side data hub, the client-side data hub does not queue events in an event queue.
Client-side data hub 1910 determines if the event should be sent to a consumer command on the server associated with the server-side data hub. If the event should be sent to a consumer command on the server, client-side data hub sends the event to the server by calling processClientEvent method 1920 via AJAX, JSON, or any other known or available remote method invocation methodology.
Server-side data hub 1900 adds the received event to an event queue 1922 . Server-side data hub 1900 processes events in the event queue, one of which is the “search/clicked” event received from the client. Server-side data hub 1900 sends the “search/clicked” event to Wiki command producer 1902 search component which is registered as a consumer for the event topic “search/clicked” 1924 . Wiki command producer 1902 search component performs the search and generates/producer search data. Wiki command producer 1902 creates an event object with topic “search/available” and attaches the generated search data to the event object.
Server-side data hub 1900 adds the “search/available” event object to the event queue. Because server-side data hub 1900 is still processing events in a processEvents phase, the “search/available” event object is immediately removed from the event queue and processed by server-side data hub 1900 . Server-side data hub 1900 then sends the “search/available” event object to Wiki command consumer 1906 because Wiki command consumer 1906 is registered as a consumer for the “search/available” topic 1926 .
Wiki command consumer 1906 saves off the new data from the “search/available” event object. Server-side data hub 1900 calls render method 1928 on all components that were involved in the processing of the original event “search/clicked” received from client-side data hub 1910 . Wiki command consumer 1906 list component render method builds a new list using hypertext markup language and JavaScript. Wiki command consumer 1906 returns the new list content to server-side data hub 1900 . Server-side data hub 1900 collects the new renderings from all components/commands involved, including Wiki command consumer 1906 , and bundles the new renderings for return to client-side data hub 1910 . Client-side data hub receives the results of processClientEvent method 1930 and updates command rendering on the client with new page content 1932 .
Next, FIG. 20 is a diagram illustrating a message flow between a server-side data hub and a client-side data hub during a page update in accordance with an illustrative embodiment of the present invention. The message flow begins when a client-side producer component fires an event with topic “clicked” concatenated with the name of the event at (message 1 ). At message 2 . 1 the client side Data hub receives the event and sends it to any listeners on the client.
The client-side Data hub determines if the event should be sent to a listener on the server (message 2 . 2 ). In these illustrative examples, a listener is a command or component registered as a consumer for a given event topic. If the event should be sent to a listener on the server, the client-side data hub sends the event to the server by calling processClientEvent or by another remote method invocation methodology (message 2 . 3 ). The server-side data hub adds the received event to the event queue (message 3 ).
At message 4 . 1 the server-side data hub processes the events in the queue, one of which is the event from the client. The server-side data hub sends the “clicked” event to the corresponding consumers that are registered as listeners (message 4 . 2 ).
The component performs the action desired by the event (message 5 . 1 ). All events are treated the same by the server-side data hub, regardless of whether the event is received from the client or from the server. The component creates a new “available” event indicating that its results are available (message 5 . 2 ). The server data hub adds the “available” event to the queue (message 6 ).
The server-side data hub processes the “available” event and sends the event to a set of consumers on the server (message 7 ). The consumer component uses the data from the “available” event object. The server-side data hub calls a render method on all components (message 8 . 1 ). All components return new renderings in hypertext markup language and JavaScript to the server-side data hub (message 8 . 2 ). The server-side data hub returns the collected renderings from all involved components to client data hub (message 9 ). The client-side data hub receives the result of the server processing of the event. The client sends the results to listeners on the client (message 10 ) for rendering page updates on the client browser.
In an alternative embodiment, processing page requests and enabling interaction between commands can also be enabled in a system in which a server-side data hub operates in accordance with the illustrative embodiments of the present invention without ever receiving events from a client-side data hub. In other examples, processing page request may be implemented, in a system in which the client is a PDA, cell phone, GPS navigator, or any other client device that does not support JavaScript.
FIG. 21 is a diagram illustrating a server-side data hub object in accordance with an illustrative embodiment of the present invention. In the depicted example, data hub 2100 is a data hub object, such as data hub 558 in FIG. 5, data hub 638 in FIG. 6, and data hub 702 in FIG. 7. In this illustrative example, data hub 2100 is a data hub object implemented in PHP.
A data hub, such as data hub 2100 , is created for each instance of a Wiki page requested by a user. A page instance is used to reference a particular page view and the page's associated data hub instance. When a request or event on the client associated with a given page is sent to the server, the server loads the specified data hub instance associated with the given page.
In other words, an instance of a data hub is created on the server for each instance of a Wiki page requested by the client. After the page instance is loaded and displayed on the client, the data hub instance for that page on the client is no longer needed. The data hub instance is saved in a memory storage device, such as storage 108 in FIG. 1. When a user enters new input or requests an action with respect to the page, the Wiki environment for the particular page view is recreated on the server by reloading the previously serialized instance of the data hub associated with the particular page view. The saved and reloaded instance of the data hub reflects the current state of the particular page on the client browser. Data hub 2100 includes attributes/object variables and a set of methods.
The set of methods includes five categories or classifications of methods. The categories of methods are as follows; data hub management 2102 , producers and consumers 2104 , topics 2106 , event processing 2108 , and command management 2110 . In these illustrative examples, a method is a procedure, function, or routine for performing an action or process associated with one or more objects, such as data hub 2100 .
The set of methods for data hub 2100 include method interfaces for methods to perform various functions, such as, saving the data hub instance, retrieving/reloading the data hub instance, adding commands, adding producers, removing producers, etc. For example, data hub management 2102 set of method interfaces includes a method interface “public static function init (page instance)” for a method to retrieve a stored instance of a data hub from data storage, such as storage 108 in FIG. 1.
Data hub 2100 also calls methods on data hub topic object 2112 and data hub event object 2114 in order to enable transfer of events between commands in the Wiki environment and client environment. Data hub topic object 2112 is primarily a data object that defines a topic that a consumer command can subscribe to. In these illustrative examples, a consumer is a command, component, or object that requires and/or requests data, an event, or input from a user, another command, another component, and/or another object in order to carry out a particular function of the command/component. In these illustrative examples, a producer is a command, component, or object that provides data, an event, or output from a user, another command, another component, and/or another object.
Data hub event object 2114 is a data object that defines a data hub event that is created by a producer and sent to a consumer for the given event topic associated with the event object.
FIG. 22 is a diagram illustrating a client-side data hub object depicted in accordance with an illustrative embodiment of the present invention. Data hub 2200 is a data hub object, such as data hub 634 in FIG. 6 and data hub 1410 in FIG. 14. In this illustrative example, data hub 2200 is a client-side data hub object implemented in JavaScript.
Data hub 2200 is a client data hub that enables Wiki components to interact with other Wiki components on the server and other Wiki components on the client. Data hub 2200 also enables Wiki components to send events generated on the client to the server for processing.
Data hub 2200 includes attributes and a set of methods. In this illustrative example, the set of methods includes four categories of methods. The categories of methods are as follows; producers and consumers 2202 , topics 2204 , event processing 2206 , and command management 2208 .
Client-side data hub 2200 also calls methods on client-side data hub topic object 2210 and client-side data hub event object 2212 in order to enable transfer of events between commands in the Wiki environment and client environment. Data hub topic object 2210 is a data hub topic object, such as data hub topic object 2112 in FIG. 21. Data hub event object 2212 is a data hub event object, such as data hub event object 2114 in FIG. 21.
Wiki page layouts are often static in one or more embodiments of the present invention. Furthermore, the static nature of Wiki page layouts and the requirement to have to individually alter the layout of each page of a set of pages makes it very time consuming to edit the layouts of a Wiki page or a set of Wiki s