Data processing: software development – installation – and managem – Software program development tool – Programming language
Reexamination Certificate
1999-10-20
2003-06-10
Ingberg, Todd (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Programming language
Reexamination Certificate
active
06578192
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention generally relates to a computer-implemented method for parsing by enabling scripts to be expressed in a language which creates, configures, and connects separately developed software objects to perform the scripted tasks. In a particular application, the method provides these services locally or on the World Wide Web (WWW). Information can be displayed that is generated or retrieved based on parameters supplied by users, in combination with data from other sources, and that is embedded into the framework of a markup language that can be represented in memory by the World Wide Web Consortium (W
3
C) Document Object Model (DOM).
2. Background Description
Initially, Web pages were static, and displayed the same information to everyone who viewed it. The Web page would remain the same until the Web Page document was edited.
Creating dynamic Web pages, where the HyperText Markup Language (HTML) tags or textual content is produced or altered automatically without human intervention, is undeniably the trend. It is now common for Web pages to offer search engine results, display information from a database, allow users to view guestbooks, or dynamically provide a frameless version for users who do not want or cannot display frames. Web services often want to display information generated or retrieved at the time the user requests them, based on parameters supplied by the users in combination with data from other sources, embedded into the framework of an HTML document.
Traditionally, dynamic content has been generated by either purely programmatic methodology such as a Common Gateway Interface (CGI) script or simple servlet, or a scripting language in the HTML page. A CGI script is a small program written in a script language such as Perl that functions as the glue between HTML pages and other programs of the Web server. CGI scripts have been the initial mechanism used to make Web sites interact, for example, with databases and other application programs. A servlet is also a small application, typically programmed in Java or Perl, that runs on an Internet or intranet server.
Microsoft's Active Server Pages (ASP) is used to create web pages written in Visual Basic (VB) Script or JScript™ that allow the web pages to interact with databases and other programs. Another alternative, Sun Microsystems JavaServer™ Pages, allows users to write their HTML framework, by inserting sections that are intercepted by the server and handed off to a programming language such as Java to perform the requested calculations.
Referring now to the drawings,
FIG. 1A
is a logical flow diagram illustrating the prior art ASP logic flow process. As shown in block
001
, when a user requests an ASP document from the server, a source document is loaded from the repository of the server. In decision block
002
, the document is scanned to determine ASP content. In decision block
003
, when an ASP sequence is encountered, as indicated by the “<%” and “%>” delimiters, the contents of the sequence, along with some context objects that provide the parameters to the script, are handed off to a scripting language interpreter
004
. Typically, most text (the HTML content of the page) from the test in decision block
003
is not in the form of an ASP script, and is consequently written directly to the output stream
005
. Finally, when the test in decision block
002
determines that there is no more text, the output stream is delivered to the client as a generated web page, as shown in block
006
.
The languages used for ASP scripting have all been fairly traditional step-by-step procedural languages. The present invention differs in its use of a language that instead describes how to assemble the scripting task from reusable software components, and in its use of document-structure rather than text-based interpretation (facilitated by the use of a scripting language which is syntax-compatible with the document markup language). Some of these languages do have object-based capability, but the user must explicitly code the low-level details of object creation, configuration, connection and invocation.
FIG. 1B
is a logical flow diagram illustrating the prior art JavaServer™ Pages (JSP) logic flow process. Unlike ASP, JSP uses Java as its scripting language, and is generally compiled to create a servlet rather than being interpreted. When the user requests a JSP document, the server begins by checking whether a compiled version is available, as shown in decision block
101
. If compilation is required, the source document is loaded, as shown in block
103
, and scanned for JSP content to determine if there is more text, as shown in decision block
104
. When a JSP sequence is encountered as shown in decision block
105
, its contents are instead written out as procedural Java code, as shown in block
107
. Most text (the HTML content of the page) is turned into print ( ) calls which will generate corresponding text into the output stream, as shown in block
106
. The generated Java is compiled to create a servlet, as shown in block
108
. Finally, the servlet, whether just compiled from block
108
or previously generated as determined by decision block
101
, is invoked in an execution context that permits it to retrieve the parameters to the script, as shown in block
102
. This servlet generates the output stream which is delivered to the client as a generated web page.
There are several disadvantages associated with these previous solutions. The most important one is that the web page developer is asked to deal with the complexities of writing and debugging executable code.
The traditional scripting languages also expose an excessive amount of detail for most dynamic content generation tasks. Their flow-control capabilities are rarely needed, and increasingly their calculating abilities go unused as well. Instead, they are often used only as a way of accessing and manipulating software objects either instantiated on demand or already residing in the processor environment of the document. One way to think of this is having gone from directly coding an operation to putting one together out of building blocks.
For example, a script may retrieve an account number from the user's request (an object provided by the evaluation environment), use it to look up the user's profile in a customer database (another object), combine the retrieved data with other information provided by the user, submit the result to an order processing engine (yet another object), and paste the resulting confirmation number into the generated webpage acknowledging the order. In more complicated scenarios, the script may set up communications channels (“wiring”) between several objects and then “step out of the way”, letting them actively negotiate among themselves to perform the requested task.
This object-oriented approach facilitates the reuse of solutions from one page to the next, easing the development and debugging task, and takes better advantage of existing code. Of course, this is not unique to the scripting environment, as programmers have been moving in the direction of plug-together software modules. But for the most part, they have used the same languages both to develop those modules and to apply them to specific tasks.
The syntactic details of using a general-purpose language to manipulate these objects can be complex enough to obscure the logic of the operation, and can be a source of programming errors. A language which hides these details, and directly represents the process of assembling a solution from software objects, will be easier for humans to write, to read, and to maintain. These advantages are especially important for authors of dynamic web pages, who often have limited programming experience.
The same simplification of syntax should also make such a language easier for other programs to manipulate. This opens up the possibility of assembling the software modules differently for different users or different requests, taking t
Boehme Richard F.
Duftler Matthew J.
Epstein David A.
Kesselman Joseph J.
Weerawarana Sanjiva
Ingberg Todd
Kaufman Stephen C.
Whitham Curtis & Christofferson, P.C.
Wood William
LandOfFree
Method and system for supporting dynamic document content... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for supporting dynamic document content..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for supporting dynamic document content... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3158415