System and method for exposing the dynamic web server-side

Abstract

A system and method for accessing a native platform API is disclosed herein. The method includes serving the application code as a container on the server-side and instantiating a content of the code with a plurality of JavaScript calls, which allows APIs to access and retrieve information from the code and to process the content of the code.

Claims

1. A method executed by a processor for creating a native application, the method comprising: providing an application assembler; providing a metadata extractor in communication with the application assembler; constructing, during development time, a metabase from a native platform application programming interface (API) by the metadata extractor, wherein the metabase contains enough metadata about the native platform functionality to provide functionality to a scripting language; assembling by the application assembler, the native application written purely in the scripting language from the metabase wherein a scripting engine is embedded in the native application; and executing the scripting engine in the native application; wherein the metabase is only used at a development time and not assembled with the native application.

2. The method of claim 1 further comprising: providing a common-native-interface (CNI) source in communication with the application assembler, wherein the CNI source that stores a CNI domain specific language (DSL) that selectively reduces the native platform's functionality.

3. The method of claim 1 further comprising: providing a common native interface (CNI); and providing an ahead-of-time (AOT) front end compiler in communication with the application assembler, wherein the AOT front end compiler selectively reduces the native platform's functionality.

4. The method of claim 1 further comprising: providing an ahead-of-time (AOT) back end compiler in communication with a scripting engine application programming interface (API).

5. A method executed by a processor for creating a native application, the method comprising: providing a metadata extractor in communication with an application assembler; constructing, during development time, a metabase from a native platform application programming interface (API) by the metadata extractor, wherein the metabase contains enough metadata about the native platform functionality to provide functionality to the scripting language; providing a common native interface (CNI) and an ahead-of-time (AOT) front end compiler in communication with the application assembler; transmitting a generated source in a scripting language from the AOT front end compiler to the application assembler; assembling the native application from the generated source and a scripting engine; and executing the scripting engine in the native application; wherein the metabase is only used at a development time and not assembled with the native application.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

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

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

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

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

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

(6) FIG. 5 is a block diagram of a callback process.

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

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

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

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

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

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

(13) 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.

(14) FIG. 12 is a block diagram of the system of the present invention used to automatically create native applications.

DETAILED DESCRIPTION OF THE INVENTION

(15) 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 file systems 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 (or 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.

(16) 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.

(17) 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. A more detailed explanation of on-the-fly processing is set forth in Colton et al., U.S. patent application Ser. No. 12/276,337, filed on Nov. 22, 2008, for a System And Method For On-The-Fly, Post-Processing Document Object Model Manipulation, which is hereby incorporated by reference in its entirety.

(18) 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.

(19) 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. A more detailed description of validating the code is set forth in Colton et al., U.S. patent application Ser. No. 12/232,5239, filed on Nov. 30, 2008, for a Client-Side And Server-Side Unified Validation, which is hereby incorporated by reference in its entirety.

(20) 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.

(21) 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.

(22) 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.

(23) The client-side preferably has a user interface. The user interface (also referred to as UI) is typically a computer which includes a processing means for interacting with various input and output devices (“I/O devices”), and various networks. The I/O Devices can be drives, a keyboard, a display, a scanner, a mouse and the like. The processing means typically includes a CPU such as an INTEL PENTIUM™ processor or the like. The processing means also preferably includes a memory (random access memory and read only memory) and interfaces for communicating with networks and the I/O Devices. The computers on the server-side are similar to the client-side, however more powerful.

(24) 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. A more detailed description of accessing the DOM on the server-side is set forth in Colton et al., U.S. patent application Ser. No. 12/277,336, filed on Nov. 22, 2008, for a System And Method For Accessibility Of Document

(25) 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. The script server architecture 50 allows for processing of web applications on-the-fly. An additional explanation of on-the-fly post processing is disclosed in Colton et al., U.S. patent application Ser. No. 12/325,240, filed on Nov. 30, 2008, for On-The-Fly, Post-Processing Of HTML Streams, which is hereby incorporated by reference in its entirety. Further details are provided in Colton et al., U.S. patent application Ser. No. 12/325,249, filed on Nov. 30, 2008, for On-The-Fly, Rewriting Of Uniform Resource Locators In A Web-Page, which is hereby incorporated by reference in its entirety. Yet further details are provided in Colton et al., U.S. patent application Ser. No. 12/326,035, filed on Dec. 1, 2008, for On-The-Fly Optimization Of Web-Applications, which is hereby incorporated by reference in its entirety. Yet further details are provided in Colton et al., U.S. patent application Ser. No. 12/326,087, filed on Dec. 1, 2008, for On-The-Fly Instrumentation Of Web-Applications, Web-Pages or Web-Sites, which is hereby incorporated by reference in its entirety.

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

(27) <html>

(28) <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); }

(29) }

(30) function saveTask(id, description)

(31) { var resultSet=Aptana.DB.execute(“SELECT * FROM tasks WHERE id=?”, [id]); if (resultSet.rows.length>0) II task already exists { Aptana.DB.execute(“UPDATE tasks SET description=? WHERE id=?”, [description, id]); { else II insert new task } Aptana.DB.execute(“INSERT INTO tasks (id, description, created)”+ “VALUES (?, ?, NOW( ))”, [id, description]); } { saveTask.proxy=true; function $(id) {return document.getElcmentById(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.setAttributc(“id”, “input_”+newId); input.setAttribute(“value”, description); Aptana.setEvent(input, “onchange”, “saveTask(“+newId+”, this.value)”); div.appendChild(input); $(“tasks”).insertBefore(div, S(“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>

(32) <head>

(33) <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)”>

(34) </div>

(35) <div id=“tasks” class=“tasks”>

(36) </div>

(37) </body>

(38) </html>

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

(40) <html>

(41) <head> <script src=“/aptandframework.js?version=0.1.1.759”
type=“text/javascript”></script>

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

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

(44) <script type=“text/javascript”>Aptana.Callback.id=−1407728339;</script>

(45) <title>Tasks</title>

(46) <style> body font: 9pt Arial; float: left; } .tasks background-color: #f0f0ff; padding: 8px; { .new-task { padding-bottom: 8px; } .task padding: 4px; }

(47) </style>

(48) <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.CallbackinvokeFunction.call(null, “saveTask”, arguments); } function saveTaskAsync(callback) { return Aptana.Callback.invokeFunctionAsync.call(null, callback, “saveTask”, arguments);

(49) }

(50) function deleteSavedTask( )

(51) { return Aptana.Callback.invokeFunction.call(null, “deleteSavedTask”, arguments);

(52) }

(53) function deleteSavedTaskAsync(callback)

(54) { return Aptana.Callback.invokeFunctionAsync.call(null, callback, “deleteSavedTask”, arguments);

(55) }

(56) </script>

(57) </head>

(58) <body>

(59) <h2>Tasks To Do</h2>

(60) <div> <i>Any changes should be automatically saved to your database!</i> <br> <br>

(61) </div>

(62) <div class=“new-task”> New:<input id=“txt_new” size=“60” type=“text”><input value=“add”
onclick=“addTask($(‘txt_new’).value)” type=“button”>

(63) </div>

(64) <div id=“tasks” class=“tasks”>

(65) </div>

(66) </body>

(67) </html>

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

(69) 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.

(70) 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.

(71) A general method 100 of the present invention is shown in FIG. 8. At block 102, a web-page of a rich web site application is retrieved on a server-side. At block 104, the web-page is served as a container. At block 106, content of the web-page is instantiated on the server-side with a plurality of JavaScript calls or a plurality of AJAX calls. At block 108, a plurality of APIs for a server-side software are provided to access and retrieve information of the web-page. At block 110, the content of the web-page is accessed with a server-side software of at least one of the plurality of APIs. At block 112, the content of the web-page is processed.

(72) FIG. 9 illustrates a flow of requests and responses utilizing the present invention. A request 91 is transmitted from a client-side 30. The request 91 is preferably for an HTML document comprising a plurality of hyperlinks or pseudo-hyperlinks (JavaScript event handlers that cause link-like behavior). The plurality of hyperlinks and/or pseudo-hyperlinks are either long, present in multiple pages of a Web-Application, pertain to a server under a heavy load and/or pertain to a file or site with a security concern. The request 91 is sent to a server-side 25 and sent to an application server 45. The application server 45 transmits a response to the client-side 30 through a script server architecture 50. The script server architecture 50, on-the-fly, processes the HTML document before the response 92 is sent to the client-side/browser 30. The processing at the script server architecture 50 comprises shortening the hyperlink, or pseudo-hyperlink, shifting the load to a different server, rerouting because of a security concern, and/or generally optimizing the hyperlink. The processing is accomplished without altering the original Web-application maintained at the application server 45. An additional explanation of on-the-fly post processing is disclosed in Colton et al., U.S. patent application Ser. No. 12/325,240, filed on Nov. 30, 2008, for On-The-Fly, Post-Processing Of HTML Streams, which is hereby incorporated by reference in its entirety.

(73) When the present invention first processes a page, before sending it to the client, it executes any JavaScript code designated to run at the server: specifically, any script blocks with a runat attribute of “server”, “both”, or one of their variants. Some of the functions defined during the processing can be designated to be available for callbacks. These functions are only available for callbacks from this page. A function is designated as callable from the browser it is in a script block with a runat=“server-proxy” attribute, or if it has a “proxy” property with a value of true, or if it's included in the Jaxer.proxies array in the page. If any of these holds, the function is cached (saved) on the server at the end of page processing, and in its place a proxy function with the same name is injected into the browser-bound page. When the proxy function is called, on the browser, it makes an XMLHttpRequest back to the server, and the server retrieves the original function and executes it; then the result is returned to the browser, where it's handled as if the proxy function returned it.

(74) In the present invention, preferably there are two proxy functions injected into the browser-bound page for every callable server-side function: one with the same name as the server-side function, and one with “Async” appended to its name. The second one is used to make asynchronous calls, ones that don't freeze the browser while the request is made to the server, processed, and returned. The Async version takes an additional first argument: a function to be called when the response is received from the server. That function takes as its arguments the returned result of the server-side function. An example is as follows:

(75) <script runat=“server-proxy”>

(76) function getLastName(first Name)}

(77) var lstName=Jaxer.DB.execute(SELECT lastName FROM names
WHERE firstNam=?”, firstName).singleResult; return lastName;
}
</script>
<script>

(78) function showFullNameNow( ) { var fistName=documentgetElementById(“first”).value; var lastNam=getLastName(firstName);

(79) show(firstName, lastName);

(80) }

(81) function showFullNameSoon( ) {

(82) var firstName=document.getElementById(“first”).value;

(83) getLastNameAsync(

(84) function(lastName) {show(firstName, lastName);},// this is called when

(85) getLastName( ) returns

(86) firstName);

(87) function show(firstName,lastName) {

(88) alert(firstName+“ ”+lastName);

(89) }

(90) </script>

(91) First name: <input type=“text” id=“first”>

(92) <input type=“button” value=“Show Now” onclick=“showFullNameNow( )”>

(93) <input type=“button” value=“Show Soon” onclick=“showFullNameSoon( )”>

(94) Note that calling the getLastName( ) function on the server is as easy as calling any function on the browser—because there actually is a getLastName( ) function on the browser, and it's a proxy for the true getLastName( ) function on the server. Using getLastNameAsync( ) requires a bit more work restructuring code to allow for the asynchronous flow, but it often means a better user experience.

(95) In many cases, other functions are needed on the server during a callback. For example, getLastName( ) requires certain access privileges. It needs to call a getCurrentUser( ) function and then call isAuthorized( ) on it. But getCurrentUser( ) and isAuthorized( ) should not be callable from the browser directly, e.g. for security reasons. To achieve this, the present invention automatically caches any other functions defined at the end of page processing (unless they're explicitly designated with runat=“server-nocache” or runat=“both-nocache”), and makes them available to other functions—but not to the browser—during a callback (the asynchronous version is omitted simplicity) as shown below.

(96) <script runat=“server”>

(97) function getCurrentUser( ) {//this will be available to other functions during a callback

(98) return Jaxer.session.get(“user”);

(99) }

(100) function isAuthorized(user) {//this will be available to other functions during a callback

(101) return user.authorizationLevel>4;// substitute some logic here

(102) }

(103) function getLastName(firstName)

(104) var user=getCurrentUser( );

(105) if(!isAuthorized(user))throw “You are not authorized”;

(106) var lastName=Jaxer.DB.execute(“SELECT lastName FROM names WHERE firstName=?”,firstName0.singleResult;

(107) return lastName;

(108) }

(109) getLastName.proxy=true;

(110) </script>

(111) <script>

(112) Function showFullName( ) {

(113) var firstName=document.getElementById(“first”).value;

(114) var lastName=getLastName(firstName);

(115) alert(firstName+“ ”+lastName);

(116) }

(117) </script>

(118) First name:<input type=“text” id=“first”>

(119) <input type=“button” onclick=“showFullName( )”>

(120) All three server-side functions getCurrentUser( ), isAuthorized( ), and getLastName( ) are saved after the page is processed and are available during a callback; but only one, getLastName( ), is allowed to be called directly from the browser, and it can then call the others as needed. It's a good practice to limit the proxied functions to only the ones actually needed by the browser to support the user interaction flow.

(121) To understand callbacks in even more detail, consider the page lifecycle. The script server architecture of the present invention loads the page and processes it, creating the DOM from the HTML and running the server-side JavaScript, which may create some functions and may manipulate the DOM. At the end of the page the HTML DOM is turned back into HTML, and the HTML is sent to the browser. The present invention then caches whatever functions may be required during a callback, destroys the server-side global “window” JavaScript context and all the JavaScript functions and data in it as well as the DOM, and prepares for its next request. The cached functions are saved to the database, but for efficiency they're also cached as bytecode in memory. Then on every callback, an empty “window” object with an empty DOM is made available, and the cached functions for that page are recreated in that window (using the bytecode in memory, after fetching from the database if needed). Finally, the specific function specified in the callback is executed.

(122) As a result of this flow, the environment available during a callback isn't the same as during the initial page. Basically, just the cached functions are available. In most cases, that works well, and is highly efficient: there's no need to recreate the entire original page to call a function, no complications trying to somehow sync the DOM during the callback to the possibly-changed DOM now on the browser, and no danger that user-specific data on that page may be available to other users, etc. However, if more control is needed, e.g. to make a server-side library available, if that server-side library consisted purely of functions, it was probably automatically cached when loaded during the initial page processing, so everything will operate. But if it requires some non-function objects to be present, the functions will need to be recreated during the callback. This can be done if the library contained an external JavaScript file to load it via <script src=“myLibrary.js” runat=“server” autorun=“true”></script>. The autorun attribute tells the present invention to automatically run this library not only on every request for this page but also on every callback on this page; for efficiency, the library is actually compiled into bytecode and stored in memory. Alternatively, a special function called oncallback can be defined in the Web-page. This special function will be executed on every callback for this Web-page,

(123) An example of code to redirect to another URL is set forth below:

(124) <html>

(125) <head> <script type=“text/javascript” runat=“server”> window.onserverload=function( ) { Jaxer.response.redirect(“/login/”); }; </script>

(126) </head>

(127) </html>

(128) An example of on-the-fly, post-processing of document object model manipulation is shown below. The HTML document is as shown below.

(129) <html>

(130) <head> <title>Widgets Intl</title>

(131) </head>

(132) <body> <h1>Widgets International</h1> <div id=“product1”>Large Widget</div>

(133) </body>

(134) </html>

(135) The DOM tree and its elements for the HTML document, with the omission of the whitespace nodes, is shown below.

(136) Element: HTML Element: HEAD Element: TITLE Text: “Widgets Intl” Element: BODY Element: H1 Text: “Widgets International” Element: DIV; Attribute: “id” with value “product1” Text: “Large Widget”

(137) The code of the present invention for manipulating the elements is as set forth below.

(138) var elt=document.getElementById(“product1”);

(139) elt.setAttribute(“style”, “font-weight: bold”);

(140) elt.innerHTML+=“&mdash; SALE!”;

(141) The DOM tree and its elements of the HTML document after the manipulation.

(142) Element: HTML Element: HEAD Element: TITLE Text: “Widgets Intl” Element: BODY Element: HI Text: “Widgets International” Element: DIV; Attribute: “id” with value “product 1” Attribute: “style” with value “font-weight bold” Text: “Large Widget—SALE!”

(143) In an embodiment illustrated in FIG. 12, the present invention can automate the creation of a program, or Native Application 433, that executes on a native platform and performs functions that can include providing the native platform's functionality under the direction of source code implemented in a Scripting Language that executes in a Scripting Engine.

(144) The functionality of the native platform provided by the Native Application 433 can be expressed in a Domain Specific Language (DSL) called Common Native Interface (CNI). The term “common” is used because the DSL uses the same language to identify native functionality from different native platforms.

(145) A central concept of the present invention is that the full fidelity of a native platform's public documented API can be available to the Scripting Language developer so that this developer can immediately become productive by simply reading existing documentation guides for the native platform in question. By providing access to the native platform's public documented API, a Scripting Language developer may be able to implement a Native Application 433 purely in the Scripting Language. A corollary to this concept is that nothing other than a native platform's public documented API may be available to the Scripting Language. In other words, it may not be possible to access a native platform's private API from the Scripting Language.

(146) To accomplish this, a Metadata Extractor 407 is used to construct a Metabase 405, or metadata database from a native platform's public documented API 409. A native platform's Metabase 405 contains enough metadata about the native platform's functionality to provide this functionality to a Scripting Language via a Scripting Engine's API. Examples of this metadata are class names, property names, property attributes, method names, method signatures, etc. A Metadata Extractor 407 creates and manages a native platform's Metabase 405. An important concept of the Metabase 405 is that the Metabase 405 is used only at development time and not at run time. In other words, the Metabase 405 is only used in the creation of a Native Application 433 and the Metabase 405 is not assembled with the Native Application 433.

(147) Although a platform's Metabase 405 may provide access to all of a native platform's public documented API 409, this may not mean that all of functionality of the native platform's public documented API 409 is made available to the Scripting Language. Instead, two other technologies called Common-Native-Interface (CNI) and Ahead-Of-Time compiling (AOT) can be used by the inventive system to selectively reduce the functionality of the native platform that is available to the Scripting Language.

(148) A Scripting Language developer can express the native functionality required by their Native Application 433 in a Domain Specific Language (DSL) called CNI DSL. This native functionality, expressed in CNI DSL, is stored in CNI Source (DSL) 401 that is the input to the CNI AST Generator 403.

(149) The Ahead-of-Time (AOT) front end compiler 413 identifies and transforms subgraphs of the CNI AST from the CNI AST Generator 403 and emits generated source code in the Scripting Language 411. The identified subgraphs of the CNI AST are those elements of the CNI Source 401 that have native proxies generated by the AOT back end compiler 415. The AOT front end compiler 413 is characterized as “Ahead of Time” because the compiler functions are performed before the execution of the Scripting Engine 429 embedded in the Native Application 433. The output of the AOT front end compiler 413 is valid generated source code expressed in the Scripting Language 411. This generated source code expressed in the Scripting Language 411 manipulates the native proxies (generated by the AOT back end compiler 415) as a part of the overall functionality of the Native Application 433.

(150) The Ahead of Time (AOT) back end compiler 415 identifies and transforms subgraphs of the CNI AST and emits native source code integrated with the Scripting Engine Application Programming Interface (API) 417 to the Enhanced Scripting Engine 429. The emitted native source code integrated with the Scripting Engine API 417 identifies elements of the native platform (as specified in the CNI Source 401) and exposes this functionality to the Enhanced Scripting Engine 425 via the Scripting Engine's API 419. The identified subgraphs of the CNI AST from the CNI AST Generator 403 are those elements of the CNI Source 401 that have native proxies. The AOT back end compiler 415 is characterized as “Ahead of Time” because the compiler functions are performed before the execution of the Scripting Engine 429 embedded in the Native Application 433.

(151) The output of the AOT back end compiler 415 is valid source code expressed in the Scripting Engine's API 419. This source code integrates all of the native functionality specified by the CNI Source 401 with the Enhanced Scripting Engine 425 (via the Scripting Engine's API 429) so that this native functionality is available to a program written in the Scripting Language that executes within the Enhanced Scripting Engine 425. The native platform's compiler 427 can include a toolchain that compiles and links this valid source code expressed in the Scripting Engine's API 419 together with the Scripting Engine 429 along with the native platform to create an enhanced Scripting Engine 425 with the native functionality specified in the CNI Source 401 such that a program written in the Scripting Language can access and interact with this native functionality when it is executed in the enhanced Scripting Engine 425.

(152) An Application Assembler 423 can then create a Native Application 433 by assembling the Native Application Program implemented in the Scripting Language 421, the Generated Source expressed in the Scripting Language 411 (the output of the AOT front end compiler 413), the Enhanced Scripting Engine 425 and the Native Bootstrap Functionality 431.

(153) 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.