METHOD FOR DEVELOPING AND MAINTAINING
CONTENT FOR WEBSITES
Field Of The Invention The present invention is generally related to software engineering for computer networks.
More specifically, the present invention relates to methods for simplifying the design, implementation and maintenance of website software and content.
Background Of The Invention
Techniques for making software simple to design and maintain are important to any software development process. This is especially true where software is being developed for use as part of a website. Projects of this type tend to be highly artistic, creative and content driven. Website development can also be somewhat informal and is often performed by a mixture of technical and non-technical contributors.
In most cases, changing website content requires a multi-step process. First the site source code is checked out from a software repository. The source code is then modified as to reflect the content change. When required, the source code is then re-compiled. Once these steps are complete, the source code can be checked back into the repository.
This multi-step process has certain drawbacks when used for website development. Arguable the most significant of these is the need for skilled software engineers to oversee the process. This is true even where the change is limited largely or completely to content, without any change to website function. The multi-step process is also relatively inflexible and not ideally suited for piecemeal changes.
For these and other reasons, a need exists for new methods for managing website content. It is important that these methods allow website content to be developed and changed without assistance from software engineers. This need is particularly relevant where website content is subject to frequent or on-going change. It is an object of the present invention to provide a method that addresses these needs.
Summary Of The Invention
An embodiment of the present invention provides a method for developing and maintaining content for websites. For a representative embodiment, each web page within a website is defined as a top-level object. Each top-level object may be recursively defined in terms of lower-level objects. The top-level and lower-level objects for the entire website are preferably stored in a database.
Each object is a snippet of HTML code and corresponds to a particular entity such as a header, navigation bar, content or footer. Objects may contain dynamic tags. Each dynamic tag is a placeholder for a particular value. In some cases, dynamic tags are placeholders for per-user data
(such as a user's name or address). Dynamic tags can also be placeholders for other objects. The software for the website includes a parser. The parser is invoked each time a web page is requested. Once invoked, the parser recursively parses the top-level object for the requested web page as well as all included lower level objects. As the parser processes each object, it replaces each instance of a dynamic tag with the tag's corresponding value.
Stated differently, an embodiment of the present invention includes a method for providing web pages, the method comprising the steps of: defining each web page as a corresponding object hierarchy, receiving a request for a specified web page, recursively parsing the corresponding object hierarchy to construct the specified web page; and returning the constructed web page.
Advantages of the invention will be set forth, in part, in the description that follows and, in part, will be understood by those skilled in the art from the description herein. The advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims and equivalents.
Brief Description Of The Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments of the invention and, together with the description, serve to explain the principles of the invention.
Figure 1 is a block diagram of a computer network shown as an exemplary environment for an embodiment of the present invention.
Figure 2 is a block diagram of a computer or terminal as used in the network of Figure 1.
Figure 4 is a block diagram showing the components of a sample web page. Figure 3 is a block diagram showing an object hierarchy that corresponds to the sample web page of Figure 3.
Detailed Description Of The Preferred Embodiments
Reference will now be made in detail to preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same of like parts.
In Figure 1, a computer network 100 is shown as a representative environment for an embodiment of the present invention. Computer network 100 is intended to be representative of the
complete spectrum of computer network types including Internet and internet-like networks.
Computer network 100 includes a number of computers, of which computers 102a through 102e are representative. Computers 102 are intended to be representative of the entire spectrum of devices that may be interconnected in computer networks. Computers 102 may also be television set top boxes, such as the WebTV system. Computers 102 may also be handheld devices such as personal data assistants or cellular telephones. Numerous other consumer devices are also possible.
Figure 2 shows a representative implementation for computers 102. Structurally, each computer 102 includes a processor, or processors 202, and a memory 204. Processor 202 can be selected from a wide range of commercially available or custom types. An input device 206 and an output device 208 are connected to processor 202 and memory 204. Input device 206 and output device 208 represent all types of I/O devices such as disk drives, keyboards, modems, network adapters, printers and displays. Each computer 102 may also includes a disk drive 210 of any suitable disk drive type (equivalently, disk drive 210 may be any non-volatile mass storage system such as "flash" memory). An embodiment of the present invention provides an object-oriented method for developing and maintaining content for websites. For the purposes of illustration, it is assumed that one of computer systems 102 is a web server and has been configured to use the method of the present invention. For that computer system 102, memory 204 includes a web server program 212, a parser program 214 and a database 216. Web server program 212 accepts requests for web pages from users of network 100. Web server program 212 responds to these requests by invoking parser program 214 to construct appropriate web pages using database 216.
Figure 2 shows web server program 212, parser program 214 and database 216 as separate entities. This particular configuration is intended to be representative in nature and other configurations are equally practical. Parser program 214 may be, for example, part of web server program 212. Parser program 214 may also be part of the software associated with database 216 or part of a middle tier (application server) positioned between web server program 212 and database 216.
Figure 2 also shows web server program 212, parser program 214 and database 216 to be resident in memory 204. It should be understood that web server program 212, parser program 214 and database 216 may be fully or partially resident in memory 204. Under certain circumstances, for example web server program 212, parser program 214 and database 216 may be fully or partially located on disk drive 210. Web server program 212, parser program 214 and database 216 may also be remotely located on two or more computers 102.
Construction of web pages by parser program 214 is better understood in terms of the simplified, representative web page 300 of Figure 3. Web page 300 includes a navigation bar 302, an
image 304, a footer 306 and a welcome banner 308. Navigation bar 302 is subdivided into buttons
310a through 310e for home, next, previous, last and first operations. Footer 304 is subdivided into button 312a showing a current page number and button 312b showing a copyright information operation. Within database 216, each web page (i.e., each entity that has it's own URL) is stored as a top-level object. Each top-level object is recursively defined in terms of zero or more lower-level objects. In the case of web page 300, the top-level object includes lower-level objects for navigation bar 302, image 304, footer 306 and welcome banner 308. Each lower-level object may also be recursively defined in terms of still lower-level objects. This is true for navigation bar 302 which is defined in terms of buttons 310a through 310e. Footer 306 is also defined in terms of lower-level objects (buttons 312a and 312b). The deconstruction of objects into lower-level objects is subject to infinite variation.
A hierarchy of objects corresponding to web page 300 is shown in Figure 4.
Each object (i.e., each top-level object and each lower-level object) is composed of a snippet of HTML code. The HTML code for each object may include any number of dynamic tags. Each dynamic tag is a placeholder for a particular value and gets replaced by that value during page construction. Depending on the particular embodiment, dynamic tags can be used to represent a range of different values. For one such embodiment, database 216 includes personal information describing users. This type of information would be available, for instance, in cases where users subscribe to particular websites or services. For this type of embodiment, dynamic tags can be used to represent particular pieces of personal information. The following example shows how objects can be used to build page 300:
<HTML> <HEAD> <TITLE>Sample usage of dynamic tags</TITLE>
</HEAD> <BODY> <_ parseObject header.global _> Welcome, <__ getFirstAndLastName _> <_ parseObject mainPage.global _>
<_ parseObject footer.global _> </BODY> </HTML>
Within this object, the dynamic tag <_getFirstAndLastName _> represents the user's name (in this hypothetical case "John Q. Public") and is replaced by parser program 214 each time web page 300 is constructed. Thus, welcome banner 308 would be appear differently if the user was "Jane Doe" or "Joe Smith".
The specific type of information stored for each user, and the range of dynamic tags used to display personal information, is entirely dependent on the particular embodiment of web server program 212, parser program 214 and database 216. Typical examples include names, addresses, phone numbers, account balances and other personal data. Dynamic tags can also implement personal link counters (i.e., how many times has this user visited this page). Dynamic tags can also be used to award points associated with web page usage. A points system is described in detail in U.S.
Application No. 09/602,168 filed June 22, 2000, entitled "Reward-based Model for ISP Service" That disclosure is incorporated in this document by reference.
The use of personal information implies that web server program 212, parser program 214 and database 216 have the ability to recognize individual users. This can be accomplished using several methods. For one method, identity information is extracted from cookies supplied by the users' browser programs. For another method, users explicitly identify themselves by logging in.
Dynamic tags can also be used to include objects within other objects. Thus, the top level object for web page 300 could include dynamic tags for the lower level objects representing navigation bar 302, image 304 and footer 306. The lower-level object for navigation bar 302 could include dynamic tags for the objects representing buttons 310a through 310e for home, next, previous, last and first operations. Footer 304 could include dynamic tags for the objects representing buttons 312a and 312b. In the sample code fragment shown above, the dynamic tag <_ parseObject footer.global _> tells the parser to include (recursively) another object. The argument following parseObject tells the parser which object to include (in this case footer.global).
Each top-level and lower-level object is preferably stored in database 216. When parser program 214 receives a request for a web page (i.e., receives a request for a specific URL) it retrieves the corresponding top-level object from database 216. Starting with that top-level object, parser program 214 begins a recursive parsing process to render the requested web page. During this process, parser program 214 replaces each instance of a dynamic tag with its corresponding value. For dynamic tags representing personal values, parser program 214 retrieves the corresponding information (e.g., first name, last name, address, account balance, etc.) from database 216. For other dynamic tags, parser program 214 may consults appropriate resources (which may include database 216) to perform the appropriate resolution. Dynamic tags that correspond to other lower-level objects cause parser program 214 to retrieve the corresponding lower-level objects from database 216. Parser program 214 then continues the recursive parsing process with the retrieved objects. In this way, the preferred parsing method resembles a depth first traversal of the top-level and lower-level objects that are included in the requested web page. It should be appreciated, however, that the depth first search order is preferred but not required. Other search orders are also possible.
Objects in database 216 may be configured and maintained using a range of methods. For one embodiment, objects in database 216 are maintained using a database maintenance interface. The maintenance interface controls the way in which users access the top-level and lower-level objects in database 216. All objects are normally provided to users on a read-only basis. To modify a particular object, a user locks the object using the maintenance interface. The maintenance interface then provides the user with read/write access to the object. This prevents simultaneous conflicting modifications to the same object by different users.
The maintenance interface is preferably configured to maintain revision control information for each object. The revision control information tracks the change history of each object — showing how each object has been modified and which user made the modification.
The maintenance interface is preferably configured support building and preview of both top- level and lower-level objects. This allows developers to see the results of any modifications they have made.
The method of the present invention effectively minimizes the need for technically skilled software developers. In practice, software development is limited to the creation of modification of dynamic tags (i.e. to creating or modifying the software that retrieves from database 216 user-specific information or performs actions in database 216 related to user's actions on the web site). Content developers, on the other hand, are free to build content that includes dynamic tags without ever having to be concerned with the details of the tags' implementations. In this way, the roles of software developer and content developer are largely separated.
Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope of the invention being indicated by the following claims and equivalents.