System and method for on-the-fly, post-processing document object model manipulation

Information

  • Patent Grant
  • 8719451
  • Patent Number
    8,719,451
  • Date Filed
    Saturday, November 22, 2008
    16 years ago
  • Date Issued
    Tuesday, May 6, 2014
    10 years ago
Abstract
A method and system for on-the-fly post-processing of a Document Object Model of a Web-page server-side is disclosed herein. The present invention analyzes the Web-page and builds a Document Object Model of the Web-page on the server-side. The present invention then identifies a plurality of elements of the Document Object Model of the Web-page for manipulation, manipulates the plurality of elements of the Document Object Model of the web-page to create a Web-page with a manipulated Document Object Model, and transmits the Web-page with the manipulated Document Object Model to the client-side.
Description
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not Applicable


BACKGROUND OF THE INVENTION

1. Field of the Invention


The present invention is related to development of Web-sites and Web-applications. More specifically, the present invention relates to document object model manipulation.


2. Description of the Related Art


Prior to Rich Internet Applications, traditional Web applications involved a client-server architecture with all of the processing on the server side and the client-side used to display the HTML web-pages served by the server. Each time a user desired to view a new Web-page, a HTTP request was sent to the server and the requested Web-page was served to the Web browser on the client-side. Such a traditional system is shown in FIG. 1 with a Web-server 1000 on a server side receiving requests over the Internet 1005 from a Web-browser 1003 on a client-side.


Rich Internet Applications, such as Ajax, greatly improved on the traditional client-server architecture by allowing the client machine to dynamically render and partially refresh web pages based on an initial set of instructions from the server, user input, and small amounts of subsequent data dynamically requested from the server. As shown in FIG. 2, the client machine processes Ajax instructions to render a Web page for the user.


Early Web applications allowed a user's browser to send a request to a server. The server processed the request and responded to the browser with a Web page. When the user wanted to view a new page, another request was sent to the server and the server responded to the browser with a new Web page. Such a process resulted in a waste of bandwidth since much of the Web contents in the first Web page were also contained in the second web page. The need to resend the same information led to a much slower user interface of a Web application than that of a native application.


An emerging technology, called Ajax (Asynchronous and JavaScript XML), was developed for refreshing part of a page instead of refreshing the whole page on every interaction between the user and application. In an Ajax application, when a user submits a form in a page, a script program, usually a JavaScript program, resident on the Web browser receives the user's request and sends a XML (Extended Markup Language) HTTP (Hyper Text Transfer Protocol) request to the Web server in background so as to retrieve only the needed Web contents instead of the whole page and perform corresponding processing to partly refresh the page when receiving a response from the Web server. In this way, the application response time is shortened, because the amount of data exchanged between the Web browser and the Web server is greatly reduced. And the processing time of the Web server is saved because much of the processing is performed at the client side.


General definitions for terms utilized in the pertinent art are set forth below.


Ajax is the use of dynamic HTML, JavaScript and CSS to create dynamic and usually interactive Web sites and applications. A more detailed explanation of Ajax is set forth in Edmond Woychowsky, AJAX, Creating Web Pages with Asynchronous JavaScript and XML, Prentice Hall, 2007, which is hereby incorporated by reference in its entirety.


Applets or Java Applets are mini-executable programs named with the .class suffix and are placed on a Web page and provide interactive and multimedia uses.


Application Programming Interface (API) is a collection of computer software code, usually a set of class definitions, that can perform a set of related complex tasks, but has a limited set of controls that may be manipulated by other software-code entities. The set of controls is deliberately limited for the sake of clarity and ease of use, so that programmers do not have to work with the detail contained within the given API itself.


An Attribute provides additional information about an element, object or file. In a Document Object Model, an attribute, or attribute node, is contained within an element node.


Behavioral layer is the top layer and is the scripting and programming that adds interactivity and dynamic effects to a site.


Binding in a general sense is the linking of a library to an application program usually to prevent repetition of frequently utilized code.


Cascading Style Sheets (CSS) is a W3C standard for defining the presentation of Web documents.


Compiler is a computer program that translates a series of instructions written in one computer language into a resulting output in a different computer language.


Document Object Model (DOM) Element is an object contained in a Document Object Model (DOM). The term DOM is generally used to refer to the particular DOM held in the memory region being used by the Web browser. Such a DOM controls the Graphical Respondent Interface (GRI) or Graphical User Interface (GUI). The DOM is generated according to the information that the Web browser reads from the HTML file, and/or from direct JavaScript software instructions. Generally, there exists a unique DOM element for every unique HTML element. DOM elements are sometimes referred to as HTML/DOM elements, because the DOM element exists only because HTML code that was read by the Web browser listed some HTML element that had not previously existed, and thereby caused the Web browser to create that DOM element. Often specific elements of the greater set of HTML/DOM elements are identified by specifying an HTML/DOM checkbox element, or an HTML/DOM text input element. A more detailed explanation of the document object model is set forth in Jeremy Keith, DOM Scripting, Web Design with JavaScript and the Document Object Model, friends of, 2005, which is hereby incorporated by reference in its entirety.


HyperText Markup Language (HTML) is a method of mixing text and other content with layout and appearance commands in a text file, so that a browser can generate a displayed image from the file.


Hypertext Transfer Protocol (HTTP) is a set of conventions for controlling the transfer of information via the Internet from a Web server computer to a client computer, and also from a client computer to a Web server.


Internet is the worldwide, decentralized totality of server computers and data-transmission paths which can supply information to a connected and browser-equipped client computer, and can receive and forward information entered from the client computer.


JavaScript is an object-based programming language. JavaScript is an interpreted language, not a compiled language. JavaScript is generally designed for writing software routines that operate within a client computer on the Internet. Generally, the software routines are downloaded to the client computer at the beginning of the interactive session, if they are not already cached on the client computer. JavaScript is discussed in greater detail below.


JSON is JavaScript Object Notation format, which is a way of taking data and turning it into valid JavaScript syntax for reconstituting an object at the other end of the transmission protocol.


MySQL is a relational database management system which relies on SQL for processing data in a database.


Parser is a component of a compiler that analyzes a sequence of tokens to determine its grammatical structure with respect to a given formal grammer. Parsing transforms input text into a data structure, usually a tree, which is suitable for later processing and which captures the implied hierarchy of the input. XML Parsers ensure that an XML document follows the rules of XML markup syntax correctly.


PHP is a scripting language that allows developers create dynamically generated Web pages, and is used for server-side programming.


Platform is the combination of a computer's architecture, operating system, programming language (PHP, JAVA, RUBY ON RAILS), runtime libraries and GUIs.


Presentation layer follows the structural layer, and provides instructions on how the document should look on the screen, sound when read aloud or be formatted when it is printed.


Rendering engine is software used with a Web browser that takes Web content (HTML, XML, image files) and formatting information (CSS, XSL) and displays the formatted content on a screen.


Serialization places an object in a binary form for transmission across a network such as the Internet and deserialization involves extracting a data structure from a series of bytes.


SQL (Structured Query Language) is a computer language designed for data retrieval and data management in a database.


Structural layer of a Web page is the marked up document and foundation on which other layers may be applied.


User is a client computer, generally operated by a human being, but in some system contexts running an automated process not under full-time human control.


Web-Browser is a complex software program, resident in a client computer, that is capable of loading and displaying text and images and exhibiting behaviors as encoded in HTML (HyperText Markup Language) from the Internet, and also from the client computer's memory. Major browsers include MICROSOFT INTERNET EXPLORER, NETSCAPE, APPLE SAFARI, MOZILLA FIREFOX, and OPERA.


Web-Server is a computer able to simultaneously manage many Internet information-exchange processes at the same time. Normally, server computers are more powerful than client computers, and are administratively and/or geographically centralized. An interactive-form information-collection process generally is controlled from a server computer, to which the sponsor of the process has access.


World Wide Web Consortium (W3C) is an unofficial standards body which creates and oversees the development of web technologies and the application of those technologies.


XHTML (Extensible Hypertext Markup Language) is a language for describing the content of hypertext documents intended to be viewed or read in a browser.


XML (Extensible Markup Language) is a W3C standard for text document markup, and it is not a language but a set of rules for creating other markup languages.


There are three types of JavaScript: 1) Client-side JavaScript; 2) Server-side JavaScript; and 3) Core JavaScript. Client-side JavaScript is generally an extended version of JavaScript that enables the enhancement and manipulation of web pages and client browsers. Server-side JavaScript is an extended version of JavaScript that enables back-end access to databases, file systems, and servers. Core JavaScript is the base JavaScript.


Core JavaScript includes the following objects: array, date, math, number and string. Client-side JavaScript and Server-side JavaScript have additional objects and functions that are specific to client-side or server-side functionality. Generally, any JavaScript libraries (.js files) created in core JavaScript can be used on both the client and the server without changes. Client-side JavaScript is composed of a Core JavaScript and additional objects such as: document, form, frame and window. The objects in Client-side JavaScript enable manipulation of HTML documents (checking form fields, submitting forms, creating dynamic pages) and the browser (directing the browser to load other HTML pages, display messages). Server-side JavaScript is composed of Core JavaScript and additional objects and functions for accessing databases and file systems, and sending email. Server-side JavaScript enables Web developers to efficiently create database-driven web applications. Server-side JavaScript is generally used to create and customize server-based applications by scripting the interaction between objects. Client-side JavaScript may be served by any server but only displayed by JavaScript-enabled browsers. Server-side JavaScript must be served by a JavaScript-enabled server but can be displayed by any browser.


Mocket et al., United States Patent Publication Number 20010037359 for a System And Method For A Server-side Browser Including Markup Language Graphical User Interface, Dynamic Markup Language Rewriter Engine And Profile Engine describes a system and method for a server-side browser including markup language graphical user interface, dynamic markup language rewriter engine and profile engine. The system includes a user computer and a destination server computer separated by a server computer hosting a server-side browser (SSB). The SSB includes a markup language graphical user interface (MLGUI), a dynamic markup language rewriter engine (DMLRE) and a profiling engine (PE). The SSB may be configured as an intermediary infrastructure residing on the Internet providing customized information gathering for a user. The components of the SSB allow for controlling, brokering and distributing information more perfectly by controlling both browser functionality (on the client-side) and server functionality (on the destination site side) within a single point and without the necessity of incremental consents or integration of either side.


Irassar et al., United States Patent Publication Number 20040250262, for Business To Business Event Communications discloses an event handling mechanism that allows communication of event information among providers and subscribers across a network using an event handling server.


Jennings et al., United States Patent Publication Number 20070073739 for a Data-Driven And Plug-In Defined Event Engine, discloses an event engine that enables application developers to define finite state machines for implementation via a data-driven approach using executable plug-ins.


Lindhorst et al., U.S. Pat. No. 6,981,215 for a System For Converting Event-Driven Code Into Serially Executed Code, discloses an event-driven server model that uses active server pages that appear to other files as objects with associated method and properties for developing Web pages.


However, current technologies that operate Server-side JavaScript fail to offer complete interactions which are the hallmark of rich web sites and applications. For example, the on-the-fly manipulation of the document object model is desired.


BRIEF SUMMARY OF THE INVENTION

The Present Invention overcomes the obstacles of the prior art. The present invention allows for post-processing DOM. Elements of the Web-page or Web-application are replaced by newer versions, removed if inappropriate, repositioned or repurposed elsewhere on the Web-page or Web-application. Also, elements of the Web-page or Web-application are re-branded, adjusted to improve accessibility for the disabled, compressed, cached, or manipulated in other ways.


The Present Invention overcomes the obstacles of the prior art. Because the present invention (usually acting as an on-the-fly post-processor) natively understands the Web content being served, it can be used to optimize that content, or to offer visibility on where the load may be reduced and the performance, both real and perceived, may be improved.


The present invention parses and executes the Web-page as a browser would parse the web-page. The present invention is configured to execute all or part of the code on that page, load external resources or not, and call various external systems in the course of processing the Web-page. As a result, the present invention can faithfully analyze the load-producing traffic in real time, e.g. monitoring how many links to certain resources are really being sent, whether they are clustered in certain ways (e.g. per page, per application or site, per user, per session), how much overlap they contain, and where do they appear and how their content is being used. In addition to reporting all this data and presenting the data in various ways to the system operators, the present invention effects certain optimizations. For example, the present invention aggregates multiple JavaScript and CSS files into single files, caches them, and replaces the multiple links to the original files into single links to the new files, thus reducing the number of network trips needed to complete the Web-page. The present invention delivers only the pieces of code that are used often, and proxies the rest of the code to deliver them on demand. The present invention reassembles JavaScript files for more optimal caching on the client and fewer network trips, and present invention can do so for images too using a technique known as image sprites. Further the present invention does all of this without changing the original code and files used to generate the web-pages. The on-the-fly (runtime) information and optimizations are then used as actionable feedback to change the original code and files or for building new code and files better.


One aspect of the present invention is a method for on-the-fly post-processing of a Document Object Model of a web-page server-side. The method includes transmitting a request for a web-page from a client-side, with the web-page comprising a Document Object Model. The method includes retrieving the web-page at a server side. The method also includes analyzing the Document Object Model of the web-page at the server-side. The method also includes identifying a plurality of elements of the Document Object Model of the web-page for manipulation. The method also includes manipulating the plurality of elements of the Document Object Model of the web-page to create a web-page with a manipulated Document Object Model. The method also includes transmitting the web-page with the manipulated Document Object Model to the client-side.


The manipulating the plurality of elements of the Document Object Model of the Web-page step preferably is replacing the plurality of elements with a newer version of the element.


The manipulating the plurality of elements of the Document Object Model of the Web-page step alternatively includes removing at least one of the plurality of elements of the Document Object Model of the Web page.


The manipulating the plurality of elements of the Document Object Model of the web-page step alternatively includes repositioning at least one of the plurality of elements of the Document Object Model of the Web page.


The manipulating the plurality of elements of the Document Object Model of the Web-page step alternatively includes repurposing at least one of the plurality of elements of the Document Object Model of the Web page.


The manipulating the plurality of elements of the Document Object Model of the Web-page step alternatively includes rebranding at least one of the plurality of elements of the Document Object Model of the Web page.


The manipulating the plurality of elements of the Document Object Model of the Web-page step alternatively includes adjusting for improved accessibility at least one of the plurality of elements of the Document Object Model of the Web page.


The manipulating the plurality of elements of the Document Object Model of the Web-page step alternatively includes compressing at least one of the plurality of elements of the Document Object Model of the Web page.


The manipulating the plurality of elements of the Document Object Model of the Web-page step alternatively includes caching at least one of the plurality of elements of the Document Object Model of the Web page.


Another aspect of the present invention is a system for on-the-fly post-processing of a Document Object Model of a Web-page on a server-side. The system includes a Web-page, a network, a Web-browser and a Web-server. The Web-page includes a Document Object Model. The web-browser having means for transmitting a request for the Web-page over the network. The Web-server includes a means for retrieving the Web-page, a JavaScript parser and engine for analyzing the Document Object Model of the Web-page, means for identifying a plurality of elements of the Document Object Model of the web-page for manipulation, means for manipulating the plurality of elements of the Document Object Model of the Web-page to create a Web-page with a manipulated Document Object Model, and means for transmitting the Web-page with the manipulated Document Object Model to the client-side over the network.


To understand the differences between the server and browser sides, it's important to keep in mind the page lifecycle. The page request from the browser is received by the Web server, which fetches the appropriate HTML document (either from the file system or perhaps from another “handler” such as PHP or Ruby or Java). The Web server (Apache server) then feeds the document to the script server of the present invention, which begins to parse the HTML document and builds up the DOM tree. When the script server encounters <script> tags the script server not only adds them to the DOM but may also execute them if they have a runat attribute that indicates they should run on the server. During the parsing and execution, external content may also be fetched and loaded into the document, via <script src=“ . . . ”></script> elements and Jaxer.load( . . . ) for JavaScript code, or via <jaxer:include src=“ . . . ”></jaxer:include> (or <jaxer:include path=“ . . . ”></jaxer:include>) for HTML content, or via XMLHttpRequests for any content. After the DOM is fully loaded, the onserverload event is fired. This is the server-side equivalent of the onload event on the browser. The onserverload event is named differently so that a developer's code can react separately to onserverload and onload events. The script server post-processes the DOM to carry out its built-in logic and prepare the DOM for sending to the browser: removing <script> blocks meant only for the server, replacing functions to be proxied with proxies, saving (as needed) functions that should be available on callbacks, . . . etc. Finally, the DOM is serialized back to HTML, and that HTML is streamed back via the Web server to the browser.


The resulting HTML page is sent back to the browser as the response to the browser's request. The browser begins to parse the HTML, building up the DOM. When the browser encounters <script> tags the browser not only adds them to the DOM but also executes them. External JavaScript code or any other content may also be loaded. The onload event fires. Of course the page is progressively rendered throughout much of this flow, and also the user can interact with it.


Callbacks from the browser to server-side functions are handled via XMLHttpRequests. When the script server receives such a request, it creates a new, empty document (unless configured to use a different static document). The script server retrieves the saved functions that are needed to be made available during callbacks to this page. If a function called oncallback is found, it is executed. This is usually used to create the environment needed during a callback, if the saved functions are not enough. The callback function itself is executed. Finally, the result of that execution is packaged and returned as the response to the XMLHttpRequest.


While a DOM is available during callback processing, it is not serialized as HTML and returned as the response, as it was during the “regular” (non-callback) page processing flow. The DOM on script server and the DOM on the browser typically are not synchronized. Both are created from the same HTML source, but they are often subject to processing by different JavaScript code, and both come to life at different points in the page lifecycle: the DOM on the script server exists temporarily when the page is processed by the script server, and is eliminated after it's been serialized into the HTML sent to the browser; the DOM in the browser is built, on the browser, from that HTML, and is the DOM that's rendered to the user and with which the end-user interacts.


While script server and the browser may well share some code (e.g. when using runat=“both”), usually the JavaScript code designated to run on script server and interacting with the script server DOM is different than the code designated to run on the client. The latter exists e.g. as a <script> tag in the script server DOM but is not executed in script server.


Remember that the only things sent to the browser at the end of page processing is what's actually in the DOM, and what the script server of the present invention has added such as proxies, clientData, and injected scripts. For example, if a developer added an expando property, which is an in-memory change to the DOM that will not get serialized, it will not appear on the client side.


var div=document.createElement (“div”);


div.id=“myDiv”;


document.body.appendChild(div);


document.getElementById(“myDiv”).userId=123;


On the browser the div is present, with an id of “myDiv”, but without a “userId” property. For this same reason, setting event handlers programmatically rather than in the DOM will not translate to DOM changes and hence will not propagate to the browser. For example with a button: <input type=“button” id=“myButton” value=“Click me”>


A developer could add an onclick=“ . . . ” attribute to the tag, but this does not assist with adding the event handler programmatically. The script server of the present invention provides Jaxer.setEvent (domElement, eventName, handler) function that “does the right thing” in the script server as well as on the browser. var btn=document.getElementById(“myButton”); function sayHi( ) {alert (“hi”)} sayHi.runat=“client”; Jaxer.setEvent(btn, “onclick”, sayHi);


The function used as the event handler should be made available to the browser. When setEvent is executed on the server, as above, it results in the following change to the myButton element: <input type=“button” id=“myButton” value=“Click me” onclick=“sayHi( )”> This is sent to the browser since it is a DOM change. If the function passed into setEvent has no name, its body (source) is used as the value of the attribute: var btn=document.getEleemntById(“myButton”); Jaxer.setEvent(btn, “onclick”, function( ) {alert(“hi”);});


This results in the following: <input type=“button” id=“myButton” value=“Click me” onclick=“(function( ) {alert(\“hi\);})( )”>


Which is useful for short functions but is easier to pass in the code to execute as a string: var btn=document.getEleemntById(“myButton”);Jaxer.setEvent(btn, “onclick”, “alert(‘hi’)”);


Which results in:<input type=“button” id=“myButton” value=“Click me” onclick=“alert(‘hi’)”>


The environment of the present invention is preferably based upon the very same Mozilla engine which powers Firefox 3. This means that, for the most part, DOM interaction in the server using the present invention is the same as interacting with the DOM in a Web browser. It parses and executes pages progressively, building up the DOM as it goes along, and allowing JavaScript to interact with whatever DOM has already been built up at the time the JavaScript executes. Any document.write( ) calls will write to the DOM immediately following the current location on the page. The JavaScript that is part of a page, and loaded into the page, executes within the context of the global window object. For each request at the server, the present invention preferably provides a document object model. This DOM (which we'll refer to as DOM1) can be used to insert data and otherwise transform the page before it is first returned to the browser. You interact with and manipulate the DOM much the same as you would in the browser. Some third party Javascript toolkits, such as jQuery, can also be used to modify this DOM. The document is accessible through the document object, and the root element of the DOM is accessible through the document.documentElement object. To ensure that element properties are serialized properly when the DOM is returned to the browser, use element.setAttribute(“attr”, “value”) rather than element.foo=“value”. Form element values set with formElement.value [code font] are an exception; they'll still be serialized as expected. To attach an event handler to an element, preferably use the special Jaxer method Jaxer.setEvent( ). Example: Transforming the DOM.


<script type=“text/javascript” runat=“server”>


window.onserverload=function( ) {

    • var textNode=document.createTextNode(“wocka wocka wocka”);
    • var element=document.getElementById(“container”);
    • element.appendChild(textNode);


};


</script>


A developer can manipulate the DOM in the API's, for example by using the following:


<script runat=“server”>






    • Document.getElementById(‘useBillingAddrChkbox’).checked=Jaxer.session.get(‘userSessionBillingAddrValue’);


      </script>





Having briefly described the present invention, the above and further objects, features and advantages thereof will be recognized by those skilled in the pertinent art from the following detailed description of the invention when taken in conjunction with the accompanying drawings.





BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS


FIG. 1 is a block diagram of a web system of the prior art.



FIG. 2 is a block diagram of a web system of the prior art.



FIG. 3 is a block diagram of the system of the present invention during a callback.



FIG. 4 is a block diagram of the system of the present invention during a normal process.



FIG. 4A is a block diagram of the system of the present invention during a normal process.



FIG. 5 is a block diagram of a callback process.



FIG. 6 is a Web-page generated by the code.



FIG. 7 is a block diagram of the server of the system of the present invention.



FIG. 7A is a block diagram of the user-computer of the system of the present invention.



FIG. 8 is a flow chart of a general method of the present invention.



FIG. 9 is a flow chart of a more specific method of the present invention.



FIG. 10 is a block diagram of a prior art application stack illustrating the interactions between the client side and the server-side.



FIG. 11 is a block diagram of an application stack of the present invention illustrating the interactions between the client side and the server-side.





DETAILED DESCRIPTION OF THE INVENTION

As shown in FIG. 3 a system 20 of the invention generally includes a server-side 25, a client side 30 and a network or preferably the Internet 35. The server-side 25 includes a web-server 40, a handler 45 and a JavaScript server 50 preferably having a server-core 55 and a server-framework 60. The client-side 30 includes a Web-browser 65 has a client-framework 70, a client-side JavaScript code 75 and a rendering engine 80. The server-framework 60 accesses filesystems 85 and databases 90, as well as the Internet 35. A more detailed description of the abilities of the running JavaScript on the server-side and client-side is disclosed in Colton et al., U.S. patent application Ser. No. 12/270,817, filed Nov. 13, 2008 for A Web Server Based On The Same Paradigms As Web-Clients, which is hereby incorporated by reference in its entirety. An additional detail of facilitated server-side to client-side communications is disclosed in Colton et al., U.S. patent application Ser. No. 12/276,327, filed Nov. 22, 2008 for a System And Method For Facilitated Client-Side To server-Side Communications, which is hereby incorporated by reference in its entirety.


In FIG. 3, the system 20 is shown during a callback operation. The callback begins at the client-side JavaScript code 75 with a callback request sent to the client-framework 70. A HTTP GET/request is transmitted over the Internet 35 to the server-side 25, and received at the Web-server 40. The HTTP GET/request is sent to the server-core 55 which sends the HTTP GET/request as a callback to the server-framework 60. The server-framework 60 receives the callback, deserializes, performs the get functions, invokes, serializes and sends the response to the callback to the server-core 55. The server-core 55 sends the response to the Web-server 40 which sends the response over the Internet 35 to client-framework 70 on the Web-browser 65.


In FIG. 4, the system 20 is shown during a normal process. The process begins with a HTTP GET/request for a Web-page sent over the Internet 35 from the Web-browser 65 on the client-side 30 to the server-side 25. The HTTP Request is sent to the handler server 45. The HTML Web-page is then sent to the script server architecture 50. The server-core 55 of the script server architecture 50 parses the HTML Web-page to create a HTML DOM of the HTML Web-page. The server-core 55 also parses and interprets the JavaScript of the HTML Web-page. The server-framework 60 accesses databases 90 and filesystems 85 to respond to the Requests for the HTML Web-page. The server-framework 60 also injects proxies to modify the HTML Web-page. The server-core 55 serializes the DOM back to the HTML Web-page and the web-server 40 transmits the HTML Web-page to the client-side 30 where the Web-browser 65 renders the HTML Web-page for display for a user. As shown in FIG. 4A, a Web server (e.g., apache server) 41 receives a request from the client-side. The request 67 is sent to the handler server (PHP, Ruby or Java language) 45. The handler server 45 feeds the HTML document to script server-core 55 which begins to parse the HTML document thereby building the DOM tree for the HTML document on the server-side. Events and callbacks are sent to the script server-framework 60. The script server adds <script> tags to the DOM and executes them if the <script> has a runat attribute that indicates the <script> should be run on the server. During the parsing and execution, external content from filesystems 85, databases 90, and the like are fetched and loaded into the HTML document. After the DOM is loaded, the onserverload event is fired from the script server framework 60. The script server architecture post-processes the DOM to perform its built in logic and prepare the DOM for transmission to the client side. This post-process includes removing <script> block meant only for the server, replacing function to be proxied with proxies, saving functions that should be available as callbacks, and the like. The DOM is serialized back to HTML, and the HTML is streamed back via the web server 41 to the browser. A more detailed explanation of event-driven JavaScript architecture is set forth in Colton et al., U.S. patent application Ser. No. 12/273,539, filed on Nov. 18, 2008, for a Flexible, Event-Driven JavaScript Server Architecture, which is hereby incorporated by reference in its entirety.



FIGS. 10 and 11 illustrate the difference in the application stacks between the prior art and the present invention. In both FIGS. 10 and 11, a client-side is designated 30 includes the HTML/DOM, CSS and JavaScript. In both FIGS. 10 and 11, arrow 91 is a request, arrow 92 is a response and arrow (both directions) 93 is a callback. The server-side 25 is the difference. The server-side 25 of the prior art is PHP, Java, RoR and C#. The server-side of the present invention is HTML/DOM, CSS and JavaScript. In the prior art, FIG. 10, Callbacks 93 require that the client-side 30 wrap, send, receive and unwrap the callback while the server-side 25 is required to receive, unwrap, run, wrap and send the callback. In the present invention, callbacks 93 are handled via XMLHttpRequests. When the server-side receives the request, the script-server architecture preferably creates a new, empty HTML document. The script-server architecture retrieves to this HTML document the saved functions needed to be made available during the callback. If a function designated oncallback is located, it is executed in order to create an environment needed during a callback, especially if the saved functions are not sufficient. Then, the callback function is executed and the results of the execution are packaged and returned as the response to the XMLHttpRequest.


As shown in FIG. 5, the present invention allows the server 50 to execute the JavaScript functions that are set to runat=“server” or runat=“both”. These functions might call databases, file systems, communicate across network sockets, or get session data. And since the server-side engine has a HTML DOM just like the browser, the HTML page can be manipulated through standard DOM APIs and your favorite Ajax libraries. The present invention also has session objects that can be used to persist data for users during a session or transaction. Any functions set to runat=“server” are stripped from what gets sent to the browser 65. Specifically at 1, the page executes on the server 50 and a resulting HTML page is sent to the browser 65. A more detailed description of the runat function is set forth in Colton et al., U.S. patent application Ser. No. 12/270,868, filed on Nov. 14, 2008, for a System And Method For Tagging Code To Determine Where The Code Runs, which is hereby incorporated by reference in its entirety.


After server 50 sends the resulting HTML page to the browser 65, at 2 the browser 65 interprets the HTML page and executes the JavaScript within the HTML page. If JavaScript functions tagged to runat=“server-proxy” are included, then the present invention automatically strips out the bodies of those functions and replaces the bodies with a new functions by the same name that know how to invoke the original function on the server 50 using Ajax calls and return the result either synchronously or asynchronously. Ajax communications do not need to be written using the present invention. Any functions not tagged with a runat attribute or set to runat=“client” or runat=“both” are processed by the browser 65.


Any functions set to runat=“server-proxy” can now be called from the browser 65. The function is called as if it were running on the browser 65, and the present invention, automatically via XHR communications with the server 50, marshals the parameters to the server 50 where the function executes (calling databases, getting info from the session data, etc. . . . ) and returns the result to the browser 65. The “server-proxy” functions can be invoked either synchronously or asynchronously. At 3, the browser 65 calls the server 50 asynchronously for new information.


The server computer program of the present invention is pre-configured for preferable use as a plug-in to the APACHE 2.x web server. To provide standards-compliant JavaScript and DOM capabilities server-side, the server computer program is built on the MOZILLA engine, which is the same engine used in the popular FIREFOX browser. The server computer program of the present invention is layered into APACHE as an input and output filter for use to modify dynamic pages created by other languages, such as PHP or Ruby.


The server computer program of the present invention is preferably a combination of C/C++“Core” code and a server-side JavaScript “Framework.” The server-core 55 provides the JavaScript parser and runtime, HTML parser and DOM engine, and an event architecture that calls the server-framework 60 as the document is being processed on the server-side 25. The server-framework 60 provides the logic, for example deciding which code to run on the server-side 25 and which on the client-side 30, creating proxies on the client-side 30 for callable server-side functions, serializing and deserializing data, and other related activities. A more detailed description of generating proxies is set forth in Colton et al., U.S. patent application Ser. No. 12/275,182, filed on Nov. 20, 2008, for a System And Method For Auto-Generating JavaScript Proxies And Meta-Proxies, which is hereby incorporated by reference in its entirety. Further discussions on proxy generation are set forth in Colton et al., U.S. patent application Ser. No. 12/275,213, filed on Nov. 20, 2008, for a Single Proxy Generation For Multiple Web Pages, which is hereby incorporated by reference in its entirety.


On the server side 25, a developer's JavaScript environment is enhanced by the server-framework 60, which provides access to the database (e.g., MySQL), file system, network, the HTTP Request and Response data, and the external server-side platforms such as Java, PHP, and Ruby.


An example of code written by a developer and prior to processing by the present invention is set forth below.

















<html>




 <head>




  <title>Tasks</title>




  <style>




   body { font: 9pt Arial; float: left; }




   .tasks {background-color: #f0f0ff; padding: 8px;}




   .new-task {Padding-bottom: 8px;}




   .task {Padding: 4px; }




  </style>




  <script type=”text/javascript” runat=”server”>




   Var sql = “CREATE TABLE IF NOT EXISTS tasks ( “+




    “id int (11) NOT NULL,” +




    “description varchar (255),”+




    “created datetime NOT NULL” +




    “) ENGINE=InnoDB DEFAULT CHARSET=utf8;




   Aptana.DB.execute(sql);




   Window.onserverload = function( )




   {




   var resultSet = Aptana.DB.execute(“SELECT * FROM




tasks ORDER BY created”);




  for (var i=0; i<resultSet.rows.length; i++)




  {




   var task = resultSet.rows[i];




   addTask(task.description, task.id);




  }




 }




 function saveTask(id, description)




 {




  var resultSet = Aptana.DB.execute(“SELECT * FROM tasks




WHERE id = ?”, [id]);




  if (resultSet.rows.length > 0) // task already exists




  {




   Aptana.DB.execute(“UPDATE tasks SET description = ?




WHERE id = ?”




    [description, id]);




  }




  else // insert new task




  {




   Aptana.DB.execute(“INSERT INTO tasks (id, description,




created) ” +




    “VALUES (?, ?, NOW( ))”,




    [id, description]);




  }




 }




 saveTask.proxy = true;




 function $(id) { return document.getElementById(id); }




 $.runat = “both”;




 function addTask(description, id)




 {




  var newId = id || Math.ceil(1000000000 * Math.random( ));




  var div = document.createElement(“div”);




  div.id = “task_ ” + newId;




  div.className = “task”;




  var checkbox = document.createElement(“input”);




  checkbox.setAttribute(“type”, “checkbox”);




  checkbox.setAttribute(“title”, “done”);




  checkbox.setAttribute(“id”, “checkbox_” + newId);




  Aptana.setEvent(checkbox, “onclick”, “completeTask




(“ + newId +”)”);




  div.appendChild(checkbox);




  var input = document.createElement(“input”);




  input.setAttribute(“type”, “text”);




  input.setAttribute(“size”, “60”);




  input.setAttribute(“title”, “description”);




  input.setAttribute(“id”, “input_” + newId);




  input.setAttribute(“value”, description);




  Aptana.setEvent(input, “onchange”, “saveTask(“ + newId + ”,




this.value)”);




  div.appendChild(input);




  $(“tasks”).insertBefore(div, $(“tasks”).firstChild);




  if (!Aptana.isOnServer)




  {




   saveTask(newId, description);




  }




 }




 addTask.runat = “both”;




 function completeTask(taskId)




 {




  var div = $(“task_” + taskId);




  div.parentNode.removeChild(div);




  deleteSavedTask(taskId);




 }




 completeTask.runat = “client”;




 function deleteSavedTask(id)




 {




  Aptana.DB.execute(“DELETE FROM tasks WHERE




id = ?”, [id]);




 }




 deleteSavedTask.proxy = true;




 </script>




</head>




<body>




 <h2>Tasks To Do</h2>




 <div><i>Any changes should be automatically saved to your




database! </i><br/><br/></div>




 <div class=“new-task”>




 New:




 <input type=“text” id=“txt new” size=“60”>




 <input type=“button” value=“add”




onclick=“addTask($(‘txt_new’).value)”>




 </div>




 <div id=“tasks” class=“tasks”>




 </div>




 </body>




</html>









Processing of the code by the present invention results in the code being formatted as set forth below:

















<html>




  <head>




    <script src=“/aptanagramework.js?version=0.1.1.759”




type=“text/j avascript”></script>




 <script type=“text/javascript”>Aptana.clientData =




Aptana.Serialization.fromJSONString(‘{ }’);</script>




 <script type=“text/javascript”>Aptana.Callback.id =-1407728339;




</script>




 <title>Tasks</title>




 <style>




  body {




   font: 9pt Arial;




   float: left;




  }




  .tasks {




   background-color: #f0f0ff;?




   padding: 8px;




  }




  .new-task {




   padding-bottom: 8px;




  }




  .task {




   padding: 4px;




  }




</style>




<script type=“text/javascript”>




  function $(id)




  {




   return document.getElementById(id);




  }




  function addTask(description, id)




  {




   var newId = id || Math.ceil(1000000000 * Math.random( ));




   var div = document.createElement(“div”);




   div.id = “task_” + newId;




   div.className = “task”;




   var checkbox = document.createElement(“input”);




   checkbox.setAttribute(“type”, “checkbox”);




   checkbox.setAttribute(“title”, “done”);




   checkbox.setAttribute(“id”, “checkbox_” + newId);




   Aptana.setEvent(checkbox,“onclick”, “completeTask




(“ + newId +”)”);




   div.appendChild(checkbox);




   var input = document.createElement(“input”);




   input.setAttribute(“type”, “text”);




   input.setAttribute(“size”, “60”);




   input.setAttribute(“title”, “description”);




   input. setAttribute(“id”, “input_” + newId);




   input.setAttribute(“value”, description);




   Aptana.setEvent(input, “onchange”, “saveTask(“ + newId + ”,




this.value)”);




   div.appendChild(input);




   $(“tasks”).insertBefore(div, $(“tasks”).firstChild);




   if (!Aptana.isOnServer)




   {




    saveTask(newId, description);




   }




  }




  function completeTask(taskId)




  {




   var div = $(“task_” + taskId);




   div.parentNode.removeChild(div);




   deleteSavedTask(taskId);




  }




  function saveTask( )?




  {




   return Aptana.Callback.invokeFunction.call(null, “saveTask”,




arguments);




  }




  function saveTaskAsync(callback)




  {




   return Aptana.Callback.invokeFunctionAsync.call(null,




callback, “saveTask”, arguments);




  }




  function deleteSavedTask( )




  {




   return Aptana.Callback.invokeFunction.call(null,




“deleteSavedTask” arguments);




  }




  function deleteSavedTaskAsync(callback)




  {




   return Aptana.Callback.invokeFunctionAsync.call(null,




callback, “deleteSavedTask”, arguments);




  }




 </script>




 </head>




 <body>




  <h2>Tasks To Do</h2>




  <div>




   <i>Any changes should be automatically saved to your




database!</i>




   <br>




   <br>




  </div>




  <div class=“new-task”>




   New:<input id=“txt new” size=“60” type=“text”><input




value=“add” onclick=“addTask($(‘txt new’).value)” type=“button”>




  </div>




<div id=“tasks” class=“tasks”>




</div>




</body>




</html>










FIG. 6 is a screen display 99 of the code set forth above.


As shown in FIG. 7, a server-computer 2000 contains server architecture 50. The server-architecture 50 includes the server-core 55 and the server-framework 60. The server-core 55 includes a JavaScript parser 95. The server-computer 2000 is preferably a conventional server-computer available from IBM, HP, APPLE, DELL, and SUN.


As shown in FIG. 7A, a user-computer 2002 contains a Web-browser 65. The Web-browser 65 preferably includes the client framework 70, client-side JavaScript code 75 and the rendering engine 80. The user-computer 2002 is preferably a conventional user-computer such as a PC available from HP, DELL, and GATEWAY, or a MAC available from APPLE. The Web-browser 65 is preferably MICROSOFT INTERNET EXPLORER, NETSCAPE, APPLE SAFARI, MOZILLA FIREFOX, or OPERA.


A general method 100 of the present invention is shown in FIG. 8. At block 102, a HTML document is provided on a web server. At block 104, the HTML DOM is analyzed on the web-server to identify a plurality of elements of the HTML DOM. At block 106, the plurality of elements of the Document Object Model of the web-page is manipulated to create a web-page with a manipulated Document Object Model. At block 108, the web-page with the manipulated Document Object Model is transmitted to the client-side.


A more specific method 200 of the present invention is shown in FIG. 9. At block 202, a HTML document is provided on a web server. At block 204, the HTML document is parsed on the web-server to create an HTML DOM. At block 206, the HTML DOM is analyzed on the web-server to identify a plurality of elements of the HTML DOM. At block 208, the plurality of elements of the Document Object Model of the web-page is manipulated to create a web-page with a manipulated Document Object Model. At block 210, the HTML DOM is serialized back to HTML. At block 212, the HTML page is transmitted to the client-side over the Internet. At block 214, the HTML page is interpreted on the web-browser for display on the user computer.


From the foregoing it is believed that those skilled in the pertinent art will recognize the meritorious advancement of this invention and will readily understand that while the present invention has been described in association with a preferred embodiment thereof, and other embodiments illustrated in the accompanying drawings, numerous changes modification and substitutions of equivalents may be made therein without departing from the spirit and scope of this invention which is intended to be unlimited by the foregoing except as may appear in the following appended claim. Therefore, the embodiments of the invention in which an exclusive property or privilege is claimed are defined in the following appended claims.

Claims
  • 1. A method for on-the-fly post-processing of a Document Object Model of a webpage server-side, the method comprising: receiving a request for the webpage from a client-side;retrieving an HTML document for the webpage at a server-side;receiving the HTML document for the webpage at a script server on the server-side on-the-fly prior to transmission to the client-side;parsing the HTML document for the webpage at the script server on the server-side;building a Document Object Model of the webpage at the script server on the server-side;identifying a plurality of elements of the Document Object Model of the webpage;manipulating the plurality of elements of the Document Object Model of the webpage to create a manipulated Document Object Model of the webpage at the script server on the server-side;serializing the manipulated Document Object Model of the webpage at the script server on the server-side into an HTML document for a webpage with a manipulated Document Object Model; andtransmitting the HTML document for the webpage with the manipulated Document Object Model to the client-side.
  • 2. The method according to claim 1 wherein manipulating the plurality of elements of the Document Object Model of the webpage comprises replacing the plurality of elements with a newer version of each element.
  • 3. The method according to claim 1 wherein manipulating the plurality of elements of the Document Object Model of the webpage comprises removing at least one of the plurality of elements of the Document Object Model of the webpage.
  • 4. The method according to claim 1 wherein manipulating the plurality of elements of the Document Object Model of the webpage comprises repositioning at least one of the plurality of elements of the Document Object Model of the webpage.
  • 5. The method according to claim 1 wherein manipulating the plurality of elements of the Document Object Model of the webpage comprises repurposing at least one of the plurality of elements of the Document Object Model of the webpage.
  • 6. The method according to claim 1 wherein manipulating the plurality of elements of the Document Object Model of the webpage comprises rebranding at least one of the plurality of elements of the Document Object Model of the webpage.
  • 7. The method according to claim 1 wherein manipulating the plurality of elements of the Document Object Model of the webpage comprises adjusting for improved accessibility at least one of the plurality of elements of the Document Object Model of the webpage.
  • 8. The method according to claim 1 wherein manipulating the plurality of elements of the Document Object Model of the webpage comprises compressing at least one of the plurality of elements of the Document Object Model of the webpage.
  • 9. The method according to claim 1 wherein manipulating the plurality of elements of the Document Object Model of the webpage comprises caching at least one of the plurality of elements of the Document Object Model of the webpage on the server-side.
  • 10. The method of claim 1 wherein the web server comprises the script server.
  • 11. The method of claim 1 wherein the web server is operatively connected to the script server on the server-side.
  • 12. The method of claim 1 further comprising the step of transmitting the HTML document for the webpage with the manipulated Document Object Model to a web server.
CROSS REFERENCE TO RELATED APPLICATION

This Application claims priority to U.S. Provisional Patent Application No. 60/989,909, filed on Nov. 23, 2007, which is hereby incorporated by reference in its entirety.

US Referenced Citations (243)
Number Name Date Kind
4989132 Mellender et al. Jan 1991 A
5361351 Lenkov et al. Nov 1994 A
5448740 Kiri et al. Sep 1995 A
5812851 Levy et al. Sep 1998 A
5821851 Blackmer Oct 1998 A
5878223 Becker et al. Mar 1999 A
6067413 Gustafsson et al. May 2000 A
6144962 Weinberg et al. Nov 2000 A
6151599 Shrader et al. Nov 2000 A
6185587 Bernardo et al. Feb 2001 B1
6192382 Lafer et al. Feb 2001 B1
6240414 Beizer et al. May 2001 B1
6324686 Komatsu et al. Nov 2001 B1
6356283 Guedalia Mar 2002 B1
6381737 Click, Jr. et al. Apr 2002 B1
6453335 Kaufmann Sep 2002 B1
6470349 Heninger et al. Oct 2002 B1
6539433 Tominaga et al. Mar 2003 B1
6609246 Guhr et al. Aug 2003 B1
6684369 Bernardo et al. Jan 2004 B1
6779114 Chow et al. Aug 2004 B1
6829746 Schwerdtfeger et al. Dec 2004 B1
6874025 Hoogenboom et al. Mar 2005 B2
6915454 Moore et al. Jul 2005 B1
6941562 Gao et al. Sep 2005 B2
6981215 Lindhorst et al. Dec 2005 B1
6990653 Burd et al. Jan 2006 B1
7000008 Bautista-Lloyd et al. Feb 2006 B2
7024689 O'Donnell et al. Apr 2006 B2
7043460 Deboer et al. May 2006 B2
7047318 Svedloff May 2006 B1
7051084 Hayton et al. May 2006 B1
7058633 Gnagy et al. Jun 2006 B1
7062506 Taylor et al. Jun 2006 B2
7086041 Plesko et al. Aug 2006 B2
7103600 Mullins Sep 2006 B2
7103881 Stone Sep 2006 B2
7117504 Smith et al. Oct 2006 B2
7124445 Cronce et al. Oct 2006 B2
7139798 Zircher et al. Nov 2006 B2
7143136 Drenan et al. Nov 2006 B1
7167862 Mullins Jan 2007 B2
7213231 Bandhole et al. May 2007 B1
7222336 Willis May 2007 B2
7231644 Kieffer Jun 2007 B2
7269636 McCollum et al. Sep 2007 B2
7284054 Radhakrishnan Oct 2007 B2
7284239 Young et al. Oct 2007 B1
7296297 Kirkpatrick et al. Nov 2007 B2
7308648 Buchthal et al. Dec 2007 B1
7313789 Yellin et al. Dec 2007 B1
7333801 Chandhok Feb 2008 B2
7386786 Davis et al. Jun 2008 B2
7389330 Dillon et al. Jun 2008 B2
7426723 Nikolov Sep 2008 B1
7451352 Moore et al. Nov 2008 B1
7454526 Brown et al. Nov 2008 B2
7478401 Irassar et al. Jan 2009 B2
7478408 Sesma Jan 2009 B2
7487201 Murray et al. Feb 2009 B1
7496841 Hadfield et al. Feb 2009 B2
7500223 DeSantis Mar 2009 B2
7506315 Kabadiyski et al. Mar 2009 B1
7509654 Jennings et al. Mar 2009 B2
7542957 Roy et al. Jun 2009 B2
7543267 Lindhorst et al. Jun 2009 B2
7543271 Gadre Jun 2009 B2
7555484 Kulkarni et al. Jun 2009 B2
7596620 Colton et al. Sep 2009 B1
7614052 Wei Nov 2009 B2
7617491 Nedderman Nov 2009 B1
7653623 Kashima et al. Jan 2010 B2
7657436 Elmore et al. Feb 2010 B2
7685609 McLellan Mar 2010 B1
7707547 Colton et al. Apr 2010 B2
7716634 Ross et al. May 2010 B2
7725530 Sah et al. May 2010 B2
7788341 Burns Aug 2010 B1
7814410 Kothari et al. Oct 2010 B2
7823009 Tormasov et al. Oct 2010 B1
7844958 Colton et al. Nov 2010 B2
7870221 Matveief et al. Jan 2011 B2
7921353 Murray Apr 2011 B1
7958232 Colton et al. Jun 2011 B1
7958493 Lindsey et al. Jun 2011 B2
20010025373 Gebhart et al. Sep 2001 A1
20010032320 Abdelnur et al. Oct 2001 A1
20010037292 Vogt Nov 2001 A1
20010037359 Mockett et al. Nov 2001 A1
20020007393 Hamel Jan 2002 A1
20020016828 Daugherty et al. Feb 2002 A1
20020023158 Polizzi et al. Feb 2002 A1
20020069255 Dinovo Jun 2002 A1
20020073235 Chen et al. Jun 2002 A1
20020099738 Grant Jul 2002 A1
20020107890 Gao et al. Aug 2002 A1
20020112247 Horner et al. Aug 2002 A1
20020138555 Yu Sep 2002 A1
20020184363 Viavant et al. Dec 2002 A1
20020199190 Su Dec 2002 A1
20030005044 Miller et al. Jan 2003 A1
20030025728 Ebbo et al. Feb 2003 A1
20030033448 Kieffer Feb 2003 A1
20030051188 Patil Mar 2003 A1
20030061404 Atwal et al. Mar 2003 A1
20030084431 Kobayashi May 2003 A1
20030088687 Begeja et al. May 2003 A1
20030105810 McCrory et al. Jun 2003 A1
20030145282 Thomas et al. Jul 2003 A1
20030177176 Hirschfeld et al. Sep 2003 A1
20030195923 Bloch et al. Oct 2003 A1
20030226110 Scheering Dec 2003 A1
20040003377 Di Loreto Jan 2004 A1
20040010621 Afergan et al. Jan 2004 A1
20040021679 Chapman et al. Feb 2004 A1
20040061713 Jennings Apr 2004 A1
20040064822 Noda Apr 2004 A1
20040066410 Lindhorst et al. Apr 2004 A1
20040123238 Hefetz et al. Jun 2004 A1
20040133848 Hunt et al. Jul 2004 A1
20040143823 Wei Jul 2004 A1
20040158843 Cloccarelli Aug 2004 A1
20040167784 Travieso et al. Aug 2004 A1
20040167876 Salerno et al. Aug 2004 A1
20040168162 Park et al. Aug 2004 A1
20040177147 Joshi et al. Sep 2004 A1
20040177335 Beisiegel et al. Sep 2004 A1
20040201618 Alderson Oct 2004 A1
20040205411 Hong et al. Oct 2004 A1
20040210865 Shimura Oct 2004 A1
20040225633 Jau Nov 2004 A1
20040236927 Irie et al. Nov 2004 A1
20040250262 Irassar et al. Dec 2004 A1
20040268303 Abe et al. Dec 2004 A1
20050005160 Bates et al. Jan 2005 A1
20050015759 Zatloukal Jan 2005 A1
20050027823 Rana Feb 2005 A1
20050028084 Dziejma Feb 2005 A1
20050043940 Elder Feb 2005 A1
20050044197 Lai Feb 2005 A1
20050066319 DeLine et al. Mar 2005 A1
20050069207 Zakrzewski et al. Mar 2005 A1
20050086344 Suesserman Apr 2005 A1
20050091576 Relyea et al. Apr 2005 A1
20050091650 Heeb Apr 2005 A1
20050102400 Nakahara et al. May 2005 A1
20050144622 Ballinger et al. Jun 2005 A1
20050160415 Kwon et al. Jul 2005 A1
20050172338 Sandu et al. Aug 2005 A1
20050177753 Carpenter Aug 2005 A1
20050182778 Heuer et al. Aug 2005 A1
20050188051 Sneh Aug 2005 A1
20050198202 Yamamoto Sep 2005 A1
20050246391 Gross Nov 2005 A1
20050256933 Millington et al. Nov 2005 A1
20050278641 Mansour et al. Dec 2005 A1
20060015842 DeSantis Jan 2006 A1
20060047780 Patnude Mar 2006 A1
20060064434 Gilbert et al. Mar 2006 A1
20060075088 Guo et al. Apr 2006 A1
20060080592 Alves de Moura et al. Apr 2006 A1
20060123397 McGuire Jun 2006 A1
20060129997 Stichnoth et al. Jun 2006 A1
20060136555 Patrick et al. Jun 2006 A1
20060136712 Nagendra et al. Jun 2006 A1
20060149746 Bansod et al. Jul 2006 A1
20060150111 Farber Jul 2006 A1
20060155707 Marcjan Jul 2006 A1
20060156279 Nelson et al. Jul 2006 A1
20060167981 Bansod et al. Jul 2006 A1
20060173998 Ohara Aug 2006 A1
20060190997 Mahajani et al. Aug 2006 A1
20060200491 Weber Sep 2006 A1
20060200503 Dosa et al. Sep 2006 A1
20060230133 Snyder et al. Oct 2006 A1
20060230149 Jackson Oct 2006 A1
20060236223 Aubert et al. Oct 2006 A1
20060253508 Colton et al. Nov 2006 A1
20060259592 Angeline Nov 2006 A1
20060277250 Cherry et al. Dec 2006 A1
20070011650 Hage et al. Jan 2007 A1
20070055964 Mirkazemi et al. Mar 2007 A1
20070061700 Kothari et al. Mar 2007 A1
20070067418 Isaacs et al. Mar 2007 A1
20070073739 Jennings et al. Mar 2007 A1
20070073806 Srinivas et al. Mar 2007 A1
20070100967 Smith et al. May 2007 A1
20070106946 Goetz et al. May 2007 A1
20070107057 Chander et al. May 2007 A1
20070113188 Bales et al. May 2007 A1
20070124311 Lee et al. May 2007 A1
20070124500 Bedingfield, Sr. et al. May 2007 A1
20070136201 Sah et al. Jun 2007 A1
20070136477 Bryce et al. Jun 2007 A1
20070143283 Spencer et al. Jun 2007 A1
20070143672 Lipton et al. Jun 2007 A1
20070150480 Hwang et al. Jun 2007 A1
20070174419 O'Connell et al. Jul 2007 A1
20070203973 Landauer et al. Aug 2007 A1
20070214239 Mechkov et al. Sep 2007 A1
20070214261 Kikuchi et al. Sep 2007 A1
20070231781 Zimmermann et al. Oct 2007 A1
20070240032 Wilson Oct 2007 A1
20070250513 Hall et al. Oct 2007 A1
20070288858 Pereira et al. Dec 2007 A1
20080005657 Sneh Jan 2008 A1
20080010338 Curtis et al. Jan 2008 A1
20080072139 Salinas et al. Mar 2008 A1
20080077556 Muriente Mar 2008 A1
20080082965 Atkin et al. Apr 2008 A1
20080104025 Dharamshi et al. May 2008 A1
20080104224 Litofsky et al. May 2008 A1
20080109680 Kodaka et al. May 2008 A1
20080140786 Tran Jun 2008 A1
20080208888 Mitchell Aug 2008 A1
20080243475 Everhart et al. Oct 2008 A1
20080244586 Hopp Oct 2008 A1
20080288739 Bamba et al. Nov 2008 A1
20080294794 Darugar et al. Nov 2008 A1
20080295004 Coca et al. Nov 2008 A1
20080295164 Steiner et al. Nov 2008 A1
20080301696 Tantawi et al. Dec 2008 A1
20080307389 Marchant Dec 2008 A1
20090013255 Yuschik et al. Jan 2009 A1
20090030926 Aharoni et al. Jan 2009 A1
20090070869 Fan et al. Mar 2009 A1
20090100154 Stevenson et al. Apr 2009 A1
20090106052 Moldovan Apr 2009 A1
20090106413 Salo et al. Apr 2009 A1
20090119675 Higgins et al. May 2009 A1
20090172792 Backhouse Jul 2009 A1
20090210631 Bosworth et al. Aug 2009 A1
20090216910 Duchesneau Aug 2009 A1
20090282136 Subramanian Nov 2009 A1
20090287734 Borders Nov 2009 A1
20090300210 Ferris Dec 2009 A1
20100035690 Blackburn et al. Feb 2010 A1
20100036903 Ahmad et al. Feb 2010 A1
20100042670 Kamalakantha et al. Feb 2010 A1
20100064234 Schreiber et al. Mar 2010 A1
20100070566 Vandewalle Mar 2010 A1
20100174607 Henkin et al. Jul 2010 A1
20100223385 Gulley et al. Sep 2010 A1
Non-Patent Literature Citations (121)
Entry
Saravanan, “LiveCycle Productivity Kit Issue”, Mar. 2007, Online Discussion; [retrieved on Apr. 10, 2012]; Retrieved from Internet <URL:http://lpk.riaforge.org/index.cfm?event=page.issue&issueid=78540FD5-F12A-3F6C-35E6 . . . >; pp. 1-11.
Portions of the file history of U.S. Appl. No. 12/270,868.
Portions of the file history of U.S. Appl. No. 12/326,833.
Portions of the file history of U.S. Appl. No. 12/325,239.
Portions of the file history of U.S. Appl. No. 12/325,240.
Portions of the file history of U.S. Appl. No. 12/326,110.
Portions of the file history of U.S. appl. No. 12/326,111.
Portions of the file history of U.S. Appl. No. 12/326,035.
Portions of the file history of U.S. Appl. No. 12/326,087.
Portions of the file history of U.S. Appl. No. 12/325,249.
Portions of the file history of U.S. Appl. No. 12/477,842.
Portions of the file history of U.S. Appl. No. 12/478,740.
Portions of the file history of U.S. Appl. No. 12/478,743.
Portions of the file history of U.S. Appl. No. 12/563,159.
Na Kika: Secure Service Execution and Composition in an Open Edge-Side Computing Network; Robert Grimm, Guy Lichtman, Nikolaos Michalakis, Amos Elliston, Adam Kravetz, Jonathan Mller, and Sajid Raza; NSDI '06: 3rd Symposium on Networked Systems Design & Implementation; 2006.
Remixing the Web: Tailoring Applications using Programmable Proxies inside Web Browsers; Leslie Wu, Joel Brandt, Scott Klemmer; Stanford Technical Report; Oct. 3, 2007.
JSMIN, The JavaScript Minifier, Douglas Crockford, www.crockford.com, Dec. 4, 2003, downloaded Sep. 13, 2011 from http://www.crockford.com/javascript/jsmin.html.
Making JavaScript Smaller: Dojo's Compressor, downloaded from the Internet WaybackMachine http://web.archive.org/web/20061114133532/http://dojotoolkit.org/docs/compressor—system.html on Sep. 13, 2011, archived on Nov. 11, 2006.
Mitchell, Scott, URL Rewriting in ASP.NET, published Mar. 2004 at http://msdn.microsoft.com/en-us/library/ms972974.aspx.
Steve Vinoski, “Scripting JAX-WS,” IEEE Internet Computing, May & Jun. 2006, pp. 91-94.
Niels Leenheer, rakaz, “Make your pages load faster by combining and compressing javascript and css files,” Dec. 18, 2006, rakaz.nl/2006/12/make-your-pages-load-faster-by-combining-and-compressing-javascript-and-css-files.html, pp. 1-4.
TrickyScripter ,by Val Polyakh 2006, archived by the Internet WayBack Machine, Nov. 2006, http://web.archive.org/web/20061113030853/http://trickyscripter.com/http://web.archive.org/web/20061113030904/http://trickyscripter.com/FAQ/,downloaded Jun. 22, 2012.
“Free JavaScript Optimizer”, by Xtreeme, http://web.archive.org/web/20071114185001/http://www.xtreeme.com/javascript-optimizer/archived by the Internet WayBack Machine Nov. 14, 2007, downloaded Jun. 22, 2012.
Kersten, Mik; Murphy, Gail C; 1999, ACM, “Atlas: A Case Study in Building a Web-Based Learning Environment Using Aspect-Oriented Programming”.
Portions of the prosecution history of U.S. Appl. No. 11/735,428.
Portions of the prosecution history of U.S. Appl. No. 12/270,817.
Portions of the prosecution history of U.S. Appl. No. 12/270,868.
Portions of the prosecution history of U.S. Appl. No. 12/273,539.
Portions of the prosecution history of U.S. Appl. No. 12/275,182.
Portions of the prosecution history of U.S. Appl. No. 12/275,213.
Portions of the prosecution history of U.S. Appl. No. 12/276,327.
Portions of the prosecution history of U.S. Appl. No. 12/276,336.
Portions of the prosecution history of U.S. Appl. No. 12/325,239.
Portions of the prosecution history of U.S. Appl. No. 12/325,268.
Portions of the prosecution history of U.S. Appl. No. 12/326,103.
Portions of the prosecution history of U.S. Appl. No. 12/326,110.
Portions of the prosecution history of U.S. Appl. No. 12/326,861.
Portions of the prosecution history of U.S. Appl. No. 12/326,891.
Portions of the prosecution history of U.S. Appl. No. 12/326,910.
Portions of the prosecution history of U.S. Appl. No. 12/327,330.
Portions of the prosecution history of U.S. Appl. No. 12/327,802.
Portions of the prosecution history of U.S. Appl. No. 12/334,434.
Portions of the prosecution history of U.S. Appl. No. 12/352,240.
Portions of the prosecution history of U.S. Appl. No. 12/563,159.
Portions of the prosecution history of U.S. Appl. No. 12/766,908.
Portions of the prosecution history of U.S. Appl. No. 12/955,881.
Portions of the prosecution history of U.S. Appl. No. 13/154,090.
Portions of the prosecution history of U.S. Appl. No. 13/175,570.
Non-Final Office Action mailed May 28, 2009 from U.S. Appl. No. 11/735,428.
Final Office Action mailed Jan. 11, 2010 from U.S. Appl. No. 11/735,428.
Non-Final Office Action mailed Jun. 23, 2010 from U.S. Appl. No. 11/735,428.
Final Office Action mailed Jan. 4, 2011 from U.S. Appl. No. 11/735,428.
Non-Final Office Action mailed May 4, 2011 from U.S. Appl. No. 12/270,817.
Final Office Action mailed Jan. 17, 2012 from U.S. Appl. No. 12/270,817.
Non-Final Office Action mailed Sep. 11, 2012 from U.S. Appl. No. 12/270,817.
Non-Final Office Action mailed Dec. 6, 2011 from U.S. Appl. No. 12/270,868.
Final Office Action mailed Aug. 29, 2012 from U.S. Appl. No. 12/270,868.
Non-Final Office Action mailed Apr. 11, 2012 from U.S. Appl. No. 12/273,539.
Final Office Action mailed Oct. 19, 2012 from U.S. Appl. No. 12/273,539.
Non-Final Office Action mailed Sep. 8, 2010 from U.S. Appl. No. 12/275,182.
Final Office Action mailed Jan. 24, 2011 from U.S. Appl. No. 12/275,182.
Non-Final Office Action mailed Aug. 24, 2012 from U.S. Appl. No. 12/275,213.
Final Office Action mailed Oct. 5, 2011 from U.S. Appl. No. 12/275,213.
Non-Final Office Action mailed Oct. 6, 2010 from U.S. Appl. No. 12/276,327.
Final Office Action mailed Apr. 4, 2011 from U.S. Appl. No. 12/276,327.
Non-Final Office Action mailed Sep. 13, 2012 from U.S. Appl. No. 12/276,336.
Non-Final Office Action mailed Sep. 19, 2011 from U.S. Appl. No. 12/326,833.
Final Office Action mailed Jul. 3, 2012 from U.S. Appl. No. 12/326,833.
Non-Final Office Action mailed May 4, 2012 from U.S. Appl. No. 12/325,239.
Final Office Action mailed Sep. 25, 2012 from U.S. Appl. No. 12/325,239.
Non-Final Office Action mailed Feb. 2, 2011 from U.S. Appl. No. 12/325,240.
Final Office Action mailed Nov. 8, 2011 from U.S. Appl. No. 12/325,240.
Non-Final Office Action mailed Oct. 24, 2012 from U.S. Appl. No. 12/325,240.
Non-Final Office Action mailed Jan. 20, 2011 from U.S. Appl. No. 12/325,268.
Non-Final Office Action mailed Oct. 17, 2011 from U.S. Appl. No. 12/325,268.
Final Office Action mailed Aug. 24, 2012 from U.S. Appl. No. 12/325,268.
Non-Final Office Action mailed Jul. 3, 2012 from U.S. Appl. No. 12/326,103.
Non-Final Office Action mailed Feb. 1, 2011 from U.S. Appl. No. 12/326,110.
Final Office Action mailed Nov. 23, 2011 from U.S. Appl. No. 12/326,110.
Non-Final Office Action mailed Oct. 22, 2012 from U.S. Appl. No. 12/326,110.
Non-Final Office Action mailed Oct. 4, 2011 from U.S. Appl. No. 12/326,861.
Final Office Action mailed Jul. 5, 2012 from U.S. Appl. No. 12/326,861.
Non-Final Office Action mailed Aug. 9, 2011 from U.S. Appl. No. 12/326,891.
Final Office Action mailed Mar. 27, 2012 from U.S. Appl. No. 12/326,891.
Non-Final Office Action mailed Sep. 29, 2011 from U.S. Appl. No. 12/326,910.
Final Office Action mailed Jun. 19, 2012 from U.S. Appl. No. 12/326,910.
Non-Final Office Action mailed Apr. 26, 2011 from U.S. Appl. No. 12/327,330.
Final Office Action mailed Feb. 26, 2012 from U.S. Appl. No. 12/327,330.
Non-Final Office Action mailed Sep. 26, 2012 from U.S. Appl. No. 12/327,330.
Non-Final Office Action mailed Aug. 20, 2010 from U.S. Appl. No. 12/327,802.
Non-Final Office Action mailed Sep. 9, 2010 from U.S. Appl. No. 12/334,434.
Final Office Action mailed Jan. 28, 2011 from U.S. Appl. No. 12/334,434.
Non-Final Office Action mailed Oct. 5, 2011 from U.S. Appl. No. 12/563,159.
Final Office Action mailed Aug. 17, 2012 from U.S. Appl. No. 12/563,159.
Non-Final Office Action mailed Oct. 11, 2012 from U.S. Appl. No. 12/955,881.
Non-Final Office Action mailed Sep. 20, 2012 from U.S. Appl. No. 13/175,570.
Non-Final Office Action mailed Sep. 14, 2011 from U.S. Appl. No. 12/326,111.
Final Office Action mailed Jul. 9, 2012 from U.S. Appl. No. 12/326,111.
Portions of the prosecution history of U.S. Appl. No. 12/325,240.
Non-Final Office Action mailed Sep. 15, 2011 from U.S. Appl. No. 12/326,035.
Final Office Action mailed May 29, 2012 from U.S. Appl. No. 12/326,035.
Non-Final Office Action mailed Aug. 12, 2010 from U.S. Appl. No. 12/326,087.
Final Office Action mailed Mar. 16, 2011 from U.S. Appl. No. 12/326,087.
Non-Final Office Action mailed Feb. 28, 2011 from U.S. Appl. No. 12/325,249.
Final Office Action mailed May 22, 2012 from U.S. Appl. No. 12/325,249.
Final Office Action mailed Oct. 4, 2011 from U.S. Appl. No. 12/325,249.
Non-Final Office Action mailed Feb. 3, 2011 from U.S. Appl. No. 12/477,842.
Non-Final Office Action mailed Oct. 20, 2011 from U.S. Appl. No. 12/477,842.
Non-Final Office Action mailed Oct. 20, 2011 from U.S. Appl. No. 12/478,740.
Final Office Action mailed Aug. 9, 2011 from U.S. Appl. No. 12/478,740.
Non-Final Office Action mailed Oct. 20, 2011 from U.S. Appl. No. 12/478,743.
Final Office Action mailed Aug. 9, 2011 from U.S. Appl. No. 12/478,743.
Gudeman, et al., Representing Type Information Dynamically Typed Languages; 1993, acquired from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.4394&rep=rep1&type=pdf, pp. 1.38.
Shao, et al., A type-based compiler for standard ML;ACM, 1995, pp. 116-129.
Server Side JavaScript Guide, Nov. 12, 1998, Netscape Communications Corp., pp. 1-4.
Lars Aronsson, Operation of a Large Scale, General Purpose Wiki Website, VWF Berlin, 2002, pp. 27-37.
Morfik announces Ajax IDE, Wednesday Sep. 28, 2005, ajaxian.com, pp. 1-3.
Susanne Hupfer, Li-Te Cheng, Steven Ross, John Patterson, Introducing Collaboration into an Application Development Environment, Nov. 6-10, 2004, ACM, vol. 6, Issue 3; pp. 21-24.
Anonymous, Creating Accessible JavaScript—JavaScript Event Handlers, published at http://webaim.org/techniques/javascript/eventhandlers.
Written Opinion of the International Searching Authority for PCT/US07/01697.
Written Opinion of the International Searching Authority for PCT/US07/66673.
Provisional Applications (1)
Number Date Country
60989909 Nov 2007 US