Drag and drop creation and editing of a page incorporating scripts6714219Abstract An environment for developing clientside/serverside code is disclosed. The environment supports programming in an event-driven paradigm while the execution of the resultant programs are executed in a serial execution paradigm. Through shielding the developer from complex scripting segments, the environment provides the developer with the suggestion that that resultant execution model is event-driven. By treating scripts as later-definable objects, the designing phase of a page may be lessened, as the appropriate codings needed to implement a page are determined at a later date. In one example, the codings may be preliminary set as server side or client side, with the environment later adding the appropriate scripting language to complete the developed page. Claims We claim: Description II. BACKGROUND OF THE INVENTION
<INPUT TYPE=SUBMIT NAME=Cancel>
<INPUT TYPE=HIDDEN NAME=Cancel_Method VALUE="CancelRequest">
When this FORM is POSTed back to its original ASP file, the code generated by the Page Object DTC sees the Cancel field in the POST information and look for the Cancel_Method field. If it finds such a field, it will use its value to determine which routine on the server page to invoke. In the above case, the Page Object DTC becomes part of a scripting model that allows a developer to write code against the page. Alternatively, it is contemplated that the initial instantiation (step 1031) may occur without a request from a browser, for example, for the purposes of broadcasting or multicasting using a push web model. Another example relates to reducing the size of a text box as displayed on the client every time a user makes a selection. As this example is similar to the states of FIG. 5, a new figure is not shown. First, the object is created on the server and its length is set to 10. Next, the object is sent to the client with the persistence information identifying the object and identifying the length of the boxes at 10. The client clicks a button, sending an onclick event to the browser. The browser sends the onclick event with the persistence information identifying the object and the length (10) back to the server. The server reinstantiates the object, modifies its length, and sends it back to the client with new persistence information (object id, length=9), and the process repeats. Note here that, as above with the balloon, the server does not need to remember what object the client has as well as the properties of the object as the client may provide this information back to the sever with each event firing. To this end, the representation of the object and all state information as modified by the events is not stored on the server, but instead discarded as the client has this information. Further, the client does not need to retransmit the entire object back to the server for event handling. Rather, the client may transmit the identification of the object as the server has the re-instantiation information stored in non-volatile memory 1030. It should also be noted that the type of code for the server and client may be different. For example, the server may run JavaScript or may run C++. So, the object may not only move seamlessly between spaces but also be translated to different scripting languages appropriate for each space (for example, JavaScript in the composition space and HTML in the interaction space). Also, it should be noted that no user interface is needed in the composition space. Rather, the only user interface needed is in the interaction space as there is generally no user visually monitoring the instantiation of objects in the composition space. This monitoring is done on in the interaction space. In the above examples, all event handling was destined for the composition space. As the smart client may in corporate some event handling, other implementations may have the client handling at least some events. F. Pages Treated as Objects Another aspect of the present invention is the paradigm of pages implemented as objects. Page Objects may be used in conjunction with ASP pages. In this sense, a page may have methods and properties associated therewith. Also, by considering a page as an object, a developer can have a first page use a second page as if the second page were an object with associated methods and properties. To this end, the developer's conception of a web project is translated to look more like a collection of objects than a set of independent ASP pages. To this end, the collection of objects appears to someone familiar with traditional programming techniques as a collection of objects. The invention also includes the use of standard web authoring and interaction techniques to provide that same programmer with familiarity for inter-document interactions. The page object aspect of the invention furthers the perception that the composition and interaction stages of a document's lifetime are part of a single object. Instead of hopping from document to document, a single document is repeatedly composed and interacted with (it repeatedly visits the composition and interaction spaces). The ability to `hop` between documents is retained, but that capability is presented consistent with the object-based metaphor that is familiar to programmers. Central to the object-based metaphor is the notion that a document has a name and that it has methods and properties. Methods may be implemented in either the local space or in the composition space. Methods which are implemented in the composition space are available for use in both composition and interaction spaces (e.g. navigate methods). Methods implemented in the local space are only available in the local space (e.g. getState/setState). Properties are available in both composition and interaction spaces. As the conventional web custom composition of a page is confusing, the page object aspect of the invention clarifies the means for customizing pages by standardizing on traditional programming techniques. The existence of a method on a document is a means of requesting custom composition of a page. The method is called, standard web techniques are employed, and the page is recomposed according to the instructions in the method. The invention ensures that this appearance of `calling a method` is maintained for the author of the document, to the point of permitting by-value parameters to be passed to the method. Also, as the conventional method of maintaining data associated with a web document is also confused, the page object aspect of the invention clarifies the means by again standardizing on traditional programming techniques. The existence of a property on a document is a means of storing data in association with that document. At least this aspect of the invention ensures that the appearance of accessing a property on the document is maintained for the author of the document. This aspect of the invention also ensures that the property value is maintained, is accessible and is modifiable in both composition and interaction spaces. Given the above, a document generally begins life in the composition space where it is initially composed (having been placed there by a designer working in a design space). Next, the composed document is moved to the interaction space. If the interaction requires recomposition of the page (invocation of a document method), the document is moved back to the composition space where it is recomposed (as discussed above with respect to FIG. 5. The recomposed document is moved back to the interaction space. This process repeats as many times as is dictated by the document and the user interactions with the document. A refinement of the overall model is that the composition and interaction spaces can be implemented in a single process and that a variety of the interoperations between the two spaces become null operations. Thus, through the use of page objects, the composition space and implementation space may be considered as a single space. The page object model of the invention also provides a means by which one document may request a transfer of execution to a different document. This is accomplished by having one document reference another using the invention at design time in the design space. The reference permits the author to gain access to the methods of another document from the current document. When the document is executing in either the composition or interaction spaces, it is possible for the document to invoke a method implemented in a referenced document. When this happens, the referenced document becomes the new document that passes between the composition and interaction spaces. Because a method is employed, by-value parameters may be used to pass information between the documents. When the change between documents takes place, the original document is discarded after saving the appropriate state information. FIG. 6 is a representation of a first page treating a second page as an object. "Page 1" 101, with the file name of page1.html, includes button 102. When button 102 is selected, "Page 2" 103, with the file name Page2.asp is accessed. For instance, page2.asp may be an active server page which accesses a database, retrieves a statistics on a person, creates an HTML page to display the statistics, and transmits the HTML page to the requesting browser. An example of the HTML representation of the script behind the button is as follows:
<input name=button
value="press me"
onclick="page2.show () ">
In the prior art, the HTML developer would have been forced to refer to page2.asp as a standard page. For example, the onclick parameter would have been represented as follows: <onclick="window.navigate.href=/windows/webpage2.asp"> accessing page2.asp as stored in the windows/web directory. The difficulty experienced in referring to page2.asp as a new destination is that the coding for the developer becomes increasingly complex with numerous ASP files (the names remembered of whose files must be) and that each ASP had to be selected separately. If two ASP files were related and only differed in a few ways, for example, if the differed in terms of the number of fields that were searchable, then the two files would have to be coded completely independently of each other. The addressing scheme of the present invention alleviates the previous addressing difficulty by allowing pages to be treated as objects (meaning that each page has its own transportable properties and methods associated with it) as well as objects being defined on the addressed pages themselves. In accordance with the invention, instead of requiring developer to separately code a new page 103 for each new button 102, the developer can embed objects in page2.asp and address the objects individually. In this regard, the developer may refer to the "show" method of page2.asp directly in the HTML code of page1.html by considering page2.asp to be an object with "show" as one of its methods. Referring to the ASP page as an object is referenced herein as an "ASP Object". ASP object methods may be are implemented as standard script methods. They may be implemented in any supported scripting language. All methods are implemented as server methods, and as a result, require that the browser navigate to the page that implements the method. To make this clear to the developer, all exported methods are available within a subobject on the page called `navigate`. This produces an invocation syntax that looks like: page.navigate.method(p1, p2, etc) As will be treated in greater detail below, the programming user interface may present a list of all available methods available on a target page. In order for programming model UI to present a list of available methods, a Page Object DTC (placed at the top of each page object) scans the page for content when the page is refreshed or accessed and parses the uncovered methods to eventually create a list of script content in the page. From this parsing, the DTC provides a scripting model against which one can write code as including the methods found on that page. Next, this knowledge of a Page Object DTC may be accessed by other pages. For example, if a developer is adding a reference to page2 from page1, the developer is interacting with the DTC on page1. When the reference (to page2 from page1) is added, the page1 DTC will examine the contents of page2, and locate the Page Object DTC information in that file. Next, it will instantiate the page2 Page Object DTC and retrieve from it a list of its object model elements. As will be described with respect to FIG. 7, the developed page 1 101 is converted from the object-oriented programming environment into an HTML environment so as to be compatible with the various servers and clients to which page 1 101 is to be eventually sent. To this end, the opportunity for a developer to design in one environment, with the created pages later converted into a less-friendly HTML environment, enables the developer to relate scripts in a natural, object-oriented way, while preserving all functionality afforded by HTML script to end servers and end users. An example of how the functionality of page 1 101 and page 103 may be implemented is as follows. The developer can place the function page2.show("Bob"), assuming one wants to look at an image of Bob, on the client's page. When interpreted into HTML script, the following would reside on the client's page:
<onclick="window.navigate.href=file: //c:
.backslash.windows.backslash.web.backslash.page2.asp?na
me=Bob">.
This representation is invisible to the client; the client only sees the button with the label "press me". Once pressed, the active server page receives the request for Bob's image in a recognizable format. This representation is also invisible to the developer; the last call the developer saw for this function was page2.show("Bob"). Since the conversion is invisible to the developer and end user, all aspects of the HTML standard (for example HTML 4.0) may be exploited without modifying the standard to accommodate the enhanced development object-oriented interface. A similar implementation is available for posting data via the POST feature of HTML, which sends back name-value pairs to the active server page. The posting of the string `Bob` is accomplished by composing a URL for the overall method invocation (e.g. page2.navigate.show(`Bob`) might become `Page2.asp?_method=show&pcount=1&p0=Bob`) and the URL is placed into a hidden field on the page. The hidden field is represented by the HTML "<INPUT TYPE=HIDDEN NAME=_method>". Setting the value of that hidden field is represented by the script "document.thisForm._method.value=`Page2. asp?_method=show&pcount=1&p0=Bob`". Posting the information is accomplished by submitting the form element on the HTML page. That is accomplished via the script "document.thisForm.submit( )". When the submit method is invoked on document.thisForm, all HTML input elements' names and values are collected together and sent in the form of an HTTP POST request to the destination URL. In this case, the destination URL may generally be the current page. The browser next re-requests the current page by sending the POST request, and the current page then unpacks the submitted information and decides what to do with the unpacked information. If the current page determines that "_method name" is represented in that information (because the _method hidden field had its value set before the POST), then the page will tell the browser to navigate to the URL indicated by the _method value. In this case, the new page is "Page2.asp?_method=. . . ". The browser sends a GET request to the server, asking for the content associated with that URL, and the server composes the page and sends it to the browser. By using the page object model of the present invention, a developer is shielded from coding the relationships. Rather, by using the page object metaphor, the designer writes code to methods in pages and the scripted interaction, as described above, is isolated from the detailed coding required to make detailed ASP pages work. The implementation of the page2.navigate.show method on the client performs all the work leading up to document.thisForm.submit( ). Also, if a navigate is performed on the server, a POST is not performed. The reason for the POST is to carry the state information being maintained about the page from the client to the server, thus keeping intact the illusion of a single object which exists in either the composition space (the server) or the interaction space (the browser). So in the case of a server-side navigate method call, a POST is not necessary because the page state information does not need to go anywhere. When the method is invoked, the page cleans itself up by navigating to a new page. FIG. 7 is a flowchart illustrating the creation of a page in an editor. In this example, the developer is editing pagea.asp. Pagea.asp has a design-time control Page Object that provides a number of property pages, including, for example, a general property page, a methods property page, a properties property page, and a reference property page. In this example, the general property page of pagea.asp may include the name of the pagea.asp (in this case, "apple"). Accordingly, pagea.asp may be referred to as "apple" by other pages. For a show method on "apple", it may be referenced as apple.show ( ). To allow one page to access a second page's methods and properties, the first page creates a reference to the second page. The reference causes the client and server script to be added to the first page, which will instantiate the desired proxy objects (as predefined in the second page) upon execution of the first page. In particular, when the reference is added, the design-time control of the first page, in one embodiment, locates the design-time control of the second page. Next, the first design-time control instantiates the second page's design-time control and ask for a description of the second page's objects. The information returned from the second page's design-time control is finally incorporated into the first page's design time control. The constructor code (a code which is placed into one file that acts as a proxy for another file) assists with the use of the page object model. The constructor code (may be referred to by the nomenclature xxxxx-ctor) enables a proxy representation of the target page in the current page so that the designer can reference the objects of the target page. Note that the current implementation is set up such that if Page1.asp is a page object, then it contains specially formatted text (known as XML) which describes the page as an object. At design time, another page which is loaded into the editor (and, therefore, has live Design Time Controls in it) can inspect the contents of Page 1.asp to determine what its methods and properties are and allow other pages to have code written against it. These property pages are described in detail in FIG. 10, below. In addition to the provided property pages mentioned above, it is recognized that additional property pages may be added as needed to incorporate other object information or other non-object information for each page. Likewise, property pages can be deleted when the environment does not need every separate page. While editing "apple" in step 301, the developer references pageb.asp (step 302). Noting that pageb.asp does not exist, the editor creates pageb.asp in step 303. Created pageb.asp is shown as page 310. After step 303, the editor inserts a Page Object DTC 311 into pageb.asp 310 in step 304. Next, if possible, the editor can attempt to populate the fields of the various property pages of new pageb.asp. Otherwise, the editor prompts the developer to describe the various methods and properties (and other information) relevant to pages (step 305). The editor may then prompt the developer for objects 312 (with methods eat, sleep, fly) to be included on page 310 (step 306). For the inclusion of objects, the developer may drag-and-drop in old objects to create a new collection of objects on the page 310. As indicated by dotted lines, next step may be included to describe the methods and properties of each new object 312 on the page 310 (step 307). The developer then proceeds to save the modifications made to the various pages (pagea.asp, pageb.asp) (step 308). The editor processes the DTCs to create appropriate scripts in new client and server pages and ASPs (step 309). While FIG. 7 relates primarily to creating a new page with new methods and properties, it is clear that creating a new page from existing pages is similar. In creating a new page from existing objects, one incorporates the existing objects into the current page. The editor performs most of the functions of incorporating the referenced objects into the new page. For example, all object properties and methods may be entirely incorporated. Alternatively, the editor may step the developer through each method and property of the new object to allow the developer to modify the properties and methods as they are incorporated into the object of the new page. An HTML example of a new ASP file is as follows:
[scripting model start code]
[Page Object DTC]
<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Visual InterDev 1.0>
<META HTTP-EQUIV="Content-Type content="text/html; charset=iso-
8859-1">
<TITLE>Document Title</TITLE>
</HEAD>
<BODY>
<!--HTML is inserted here--!>
</BODY>
</HTML>
<%
scripting model end code
%>
In this example, the call to the EndPageContent( ) method terminates the page. This page will eventually contain, or be referred to as, an object. To explain how the objects between pages can interrelate, the interactions with respect to methods and properties are now described. First, methods may be implemented as standard script models in any supported scripting language. Methods may interact in one of two ways: the method may require navigation to a new page or may be executed in the background and keep the end user's browser on a given page. FIGS. 8 and 9 describe these processes in detail from the browser's perspective. FIG. 8 shows the receipt of a page in step 401. Next, the end user selects a method with the name of <foo.navigation.method( )> (relating to file foo) in step 402. The browser unloads the current page (step 403), grabs the new page foo with its method method (step 404) and runs the new page (405). FIG. 9 relates to the execution of a method with no new navigation in the client's browser. FIG. 9 shows the receipt of a page in step 501. Next, the end user selects a method with the name of <foo.execute.method ( )> in step 502. In contrast to step 403, the browser keeps the current page (step 503), and grabs the new page (504), which accesses the method method. Finally, while the method method may be running elsewhere (or it may be running on the client), the client's browser receives the data generated by the method and returns them to the currently running page (505). To the extent that information is displayed by the new method, the method effectively appears to run in the current page. FIG. 9 may be understood with relation to the following example: a browser has downloaded a page with various fields for entry of various baseball players' names along side a reserved field. The end user next selects the name of player Bob and transmits "Bob" to the server storing Bob's information. Instead of dumping the current page with the field bearing the data "Bob", the browser keeps the current page and populates the reserved field with the new information (for example, Bob's batting average). Before the current invention, previous web page developers had to create complex cookie sets for storing the entered information locally then repopulating cleared fields with cookie information. Alternatively, previous web page designers had to store the uploaded fields on a server temporally, repackage the stored information into a new page with the retrieved information, and download the combined web page. To this end, developers were hampered by the complex temporary data storage tasks needed to handle even the smallest of queries. With the present invention, the temporary storage problem is minimized, if not eliminated. FIG. 10 shows how the property pages may be ordered in a DTC page object 602 of a page 601. The DTC 602 supports three property pages: a methods property page 604, a properties property page 605, and a reference property page 606. Each property page has information that can be toggled according to the developer's wishes. The method property page 604 indicates that page 601 contains three methods in it. The methods include "eat", "sleep", and "fly". The property page 604 also indicates where the methods may be exported. The exportation and the accessibility may be switched between choices. For example, the eat method may be exported to both the server and the client, the sleep method may be exported to the client only, and the fly method may be exported to the server only. Also, the eat method may be accessible from both the client and the server, the sleep method accessible from the client only, and the fly method accessible from the server only. As used herein, being "exported" means that a method (implemented within the page on the server) should be accessible in some way either on the client or on the server. Being "accessible" from the client or the server means that contributions to the namespace of either the client or the server appear so that the method can be called from the client or the server. In particular, a proxy method is provided and is callable from script, which will navigate or redirect a browser to the proper URL. One example of the implementation simply allows the designer to export a method. As disclosed herein, the method may be accessible from both client and server. An example of this accessibility is for the user to implement a "fly" method, go to the Page Object Methods property page, and add that method to the Navigate Methods grid. On the page, script can then call "thisPage.navigate.fly" in both the composition (server) and interaction (browser) execution spaces. Note, the first four lines through "%>" represent an example of the scripting model start code.
<%@ Language=VBScript %>
<% ` VI 6.0 Scripting Object Model Enabled %>
<!--#include file="_ScriptLibrary/pm.asp"-->
<% if StartPageProcessing () Then Response.End () %>
<FORM name=thisForm METHOD=post>
<HTML>
<HEAD>
<META name="VI60_DTCScriptingPlatform" Content="Client (IE 4.0
DHTML) ">
<META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0">
<SCRIPT LANGUAGE=vbscript RUNAT=Server>
Sub fly ()
` do nothing
End Sub
</SCRIPT>
</HEAD>
<BODY>
<!--METADATA TYPE="DesignerControl" startspan
<OBJECT classid="clsid:8CC35CD6-E98B-11D0-B218-00A0C92764F5"
id=PageObject1 style="LEFT: 0px; TOP: 0px">
<PARAM NAME="ExtentX" VALUE="4233">
<PARAM NAME="ExtentY" VALUE="1508">
<PARAM NAME="State"
VALUE=" (ObjectName_Unmatched=.backslash.qPatent.backslash.q,
NavigateMethods= (Rows=1, R
ow1= (Name=.backslash.qfly.backslash.q,
Parameters_Unmatched=.backslash.q0.backslash.q)), ExecuteMethods= (Ro
ws=0), Properties= (Rows=0), References= (Rows=0)) "></OBJECT>
-->
<SCRIPT LANGUAGE=JavaScript RUNAT=SERVER>
/* VIPM PAGE DESCRIPTION
<DSC NAME="Patent">
<OBJECT NAME="navigate">
<METHOD NAME="fly" SCENARIOS="CLIENT, SERVER"/>
<METHOD NAME="show" SCENARIOS="CLIENT, SERVER"/>
</OBJECT>
</DSC>
VIPM PAGE DESCRIPTION */
</SCRIPT>
<%
Sub [_PO_OutputClientCode] ()
%>
<SCRIPT LANGUAGE=JavaScript>
if (typeof Patent_onbeforeserverevent == `function` .vertline..vertline.
typeof
Patent_onbeforeserverevent == `unknown`)
thisPage.advise (`onbeforeserverevent`,
`Patent_onbeforeserverevent () `);
Patent = thisPage;
Patent.location = "Patent.asp";
Patent.navigate = new Object;
Patent.navigate.fly = Function (`thisPage.invokeMethod ("", "fly",
this.fly.arguments);`);
Patent.navigate.show = Function (`thisPage.invokeMethod ("",
"show", this.show.arguments);`);
</SCRIPT>
<%
End Sub
%>
<SCRIPT LANGUAGE=JavaScript RUNAT=SERVER>
function _PO_getClientAccessor (serverValue)
{
if (serverValue == null)
return `null`;
return `unescape ("` + escape (serverValue) + `")`;
}
function _PO_ctor ()
{
thisPage.getClientAccessor = _PO_getClientAccessor;
Patent = thisPage;
Patent.location = "Patent.asp";
Patent.navigate = new Object;
Patent.navigate.fly = Function (`return fly ();`);
Patent.navigate.show = Function (`return;`);
thisPage._objEventManager.adviseDefaultHandler (`Patent`, `one
nter`);
thisPage._objEventManager.adviseDefaultHandler (`Patent`, `one
xit`);
thisPage.registerVTable (thisPage.navigate, PAGE_NAVIGATE);
}
function _PO_dtor ()
{
if (thisPage._redirect == ``)
_PO_OutputClientCode ();
}
</SCRIPT>
<!--METADATA TYPE="DesignerControl" endspan-->
<P> </P>
</BODY>
<% ` VI 6.0 Scripting Object Model Enabled %>
<% EndPageProcessing () %>
</FORM>
</HTML>
The following sample of the above allows both the server and client to access the method.
<DSC NAME="Patent">
<OBJECT NAME="navigate">
<METHOD NAME="fly" SCENARIOS="CLIENT, SERVER"/>
<METHOD NAME="show" SCENARIOS="CLIENT, SERVER"/>
</OBJECT>
</DSC>
As with the methods property page 604, the properties property page 605 shows various characteristics of the properties. Here, three properties are on page 601: run, walk, and jog. The attributes include the type of property (session, page or application), the type of access (read-only, read/write), and to where the property exported/accessed. Other objects may not be contained within page 601. However, they may be referenced via placement in the reference page 606. To include an object in the page, the developer may drag and drop an object into the reference page and have all methods and properties included automatically. Finally, the general property page 603 relates to general information about page 601 (for example, its name). FIGS. 11 and 12 show a property exchange feature according to embodiments of the present invention. A property may be declared by the developer as being part of the ASP object, while its value may be stored in a server-side location. Alternatively, the values of the property may be stored in said ASP object itself. FIG. 11 shows an ASP proxy object 704 located on server 701. When an ASP object is loaded by a server, the property values are retrieved 706 (from wherever they are stored 703) and are placed into the proxy objects properties 704. Also, the proxy object's properties for the client are prepared and stored in ASP object 704 as well. During construction of the page, the proxy objects' properties may be accessed and modified by the server script. If modified, the properties maybe sent back 707 to the data storage 703 for future retrieval. When the page is delivered to the client 702 by data flow 707, the page properties are transmitted to the client as well. Generally, the properties of the objects sent to the client are marked read-only (meaning that server 701 will not accept any modifications of the properties from the client 702). The read-only status was previously set by the developer in the properties property page 605 of FIG. 6. FIG. 12 relates to the posting of modified property information back to data storage 703. If the page property is marked read/write, the modified property is transmitted back to server 701, for example, by the client navigating to a new page or by posting 801 its data to the new page. Once the new page on the server receives the updated information, the modifications are combined and transmitted 802 to data storage 703. In general, a page property is referred to as page.property=<%=server location%>. At least three server locations may be supported. The locations are referred to as the "lifetimes" of the properties. The three locations include on a page, in a session, and in an application. The term "on the page" means that the property is initialized to the null string when the page is composed. When the page is completed, no action is taken to modify the property. The session property is initialized from the session variable when the page is composed. When the page composition is complete, the session variable is updated. In the application location is treated the same as the session variable. During normal operation of an ASP Object, a page is composed, delivered to the browser, run and then client script causes the browser to navigate to a new page, possibly another ASP Object. The browser advances to the desired page immediately. No changes to state by the client are automatically propagated back to the server. If the developer needs to move state back to the server, it may be manually coded using FORM elements, cookies, etc. If the developer requests it, the programming model can operate such that changes to state can be sent back to the server. The operation of an ASP Object in this mode is the same as above, except that when client script is invoked to advance to the next page, the page state is collected, then it is delivered to the same page using a FORM POST, the state information is saved and then a redirect is used to advance the browser to the desired page. The following provides examples of the invocations of the various techniques mentioned above as compared to conventional programming practices. a) Method Invocation When navigating from one page to another or even back to the same page, a conventional technique is to place one of the following constructs onto the page:
<SCRIPT LANGUAGE=VBSCRIPT>
Sub button_onclick ()
window.location.href =
"reports/topscores.asp?category=baseball&start=1936&end=1945"
End Sub
</SCRIPT>
or
<A
HREF="reports/topscores.asp?category=baseball&start=1936&end=1945
">Baseball Scores</A>
Both constructs involve reacting to some user action to cause the browser to move to a new page or to revisit the current page. The constructs get more involved when variables are used as part of the destination URL:
<SCRIPT LANGUAGE=VBSCRIPT>
Sub button_onclick ()
parameters = "?category=" & catCurrent
parameters = parameters & "&start=" & datStart
parameters = parameters & "&end=" & datEnd
window.location.href = "reports/topscores.asp" & parameters
End Sub
</SCRIPT>
The complications continue if a parameter is to be completely omitted:
<SCRIPT LANGUAGE=VBSCRIPT>
Sub button_onclick ()
parameters = "?"
If Not IsNull (catCurrent) Then
parameters = "category=" & catCurrent
End If
If Not IsNull (datStart) Then
parameters = parameters & "&start=" & datStart
End If
If Not IsNull (datEnd) Then
parameters = parameters & "&end=" & datEnd
End If
window.location.href = "reports/topscores.asp" & parameters
End Sub
</SCRIPT>
The page object model aspect of the current invention collapses all of this into a single, programmatic notation:
<SCRIPT LANGUAGE=VBSCRIPT>
Sub button_onclick ()
TopScores.navigate.show (catCurrent, datStart, datEnd)
End Sub
</SCRIPT>
The significant information is passed to a routine on an object that represents the file "reports/topscores.asp". That object is called "TopScores" and was explicitly named by the web site author. The "show" method was also explicitly created by the author of the "TopScores" page. The invention includes capabilities, which are common to programming tools, such as `statement completion`. This is an aid that is provided to the author where as the method invocation is typed, prompts are presented which describe the available choices at a given point. Those prompts include a list of methods available and, once a method is selected, a list of the parameters that should be passed to the method. Internal to a method invocation supported by the invention, the same sort of operation performed in the samples above is accomplished behind the scenes. The parameters are converted to text, concatenated together as appropriate into a URL and then that URL is contained in the information sent to the composition space. Once received, the information is unpacked and the actual method, which exists in the composition space, is invoked. The invocation is actually more complicated than that and a number of other operations are intermingled with the ones described. However, the essentials are covered by the above. b) Property Management There are four aspects to managing property information on a web page: access in the composition space, propagation to the interaction space, access in the interaction space, and propagation to the composition space. Each of these four aspects requires a specific technique or techniques, and the resulting content in the authored page can be nearly impossible to maintain. Because the invention considers all four aspects to be part of a single problem, the invention presents the single concept of a page property to solve that problem. A page property is created by an author. The author chooses the name of the property, how it may be accessed in the composition and interaction spaces (read-only versus read-write, etc), and its `lifetime`. The lifetime is a statement of where the data of the property should be officially stored. There are three lifetimes: page, session and application. The notion of `forever` would be another lifetime that might suggest storage in a database on the server. The invention does not provide an implementation of a `forever` lifetime, but it is easily within the scope of the invention. The invention provides access to property values via `get` and `set` methods. Those methods are referenced as variable=TopScores.getproperty( ) TopScores.setproperty(variable) This notation is used identically in the composition and interaction spaces. (1) Access in the Composition Space Script running during composition retrieves the latest value from the appropriate storage location at the beginning of page composition and automatically stores changes to that location as changes are made. All access is accomplished via getproperty and setproperty methods associated with the page object. (2) Propagation to the Interaction Space Script running at the end of the composition phase outputs script that provides the necessary object model in the interaction space. That script includes the values of the various pieces of data as initializers to internal variables. Also output are a set of hidden input fields that will be used in item 4 below. (3) Access in the Interaction Space As with the composition space II access is accomplished via getproperty and setproperty methods associated with the page object. (4) Propagation to the Composition Space As changes are made to properties via setproperty methods in the interaction space, the changed values are stored in the hidden input fields created in item 2. When the user interacts with the page such that a method in a page should be executed, the property values are propagated back to the composition space by posting the current page's FORM element. That post operation causes the hidden input fields to be sent to the composition space where they are unpacked and stored in the appropriate data storage, as well as being made available to a new pass through the composition space--starting with item 1. There are sufficient controls provided by the invention that an author can control a variety of aspects of data management, including permitting access only within the composition space or access only within the interaction space, etc. c) Controlling Composition The invention changes the normal pattern of page composition of an ASP. That is, it takes advantage of the very general page composition approach used, and creates a more specific approach. The standard ASP page composition technique is to process the page from the beginning to the end, generating output as the page is processed. The invention introduces a variety of notions, including `events` that are fired at the beginning and end of page composition. Also part of the invention's innovations is the execution of a page method as described above. The composition process of a page object may follow these steps: 1. Run all constructors defined on the page. Constructors are usually added to the page by Design Time Controls, which leverage the invention's page composition model. 2. Fire the oninit event, completing any initialization steps that could not happen in the construction phase. As above, oninit event handlers are usually added to the page by Design Time Controls. 3. Fire the onenter event, which is usually implemented by the page author and permits execution of page initialization operations. 4. Invoke the requested method on the page. 5. Complete conventional processing on the page. This means that the page is processed from beginning to end as a conventional ASP would. There are controls provided by the invention to skip this step, which is usually what happens when the requested method generates the complete response that would normally be generated by processing the page. 6. Fire the `onexit` event. 7. Run all destructors defined on the page. As with the constructors, destructors are usually added to the page by Design Time Controls. Various objects may be incorporated into the scripting libraries as discussed above. The objects and their definitions may include: Page--Allows developers to treat ASP pages as objects with methods, properties, and events Recordset--Supports data-binding to an ADO recordset using the Data Environment Textbox--A data-bound textbox Label--A data-bound label Listbox--A data-bound listbox with static or data-bound lookup values Button RSNavBar--A set of buttons for navigating through a list of items Checkbox OptionGroup The sections below show some examples of web programming tasks and how the SOM makes implementing them easier and simpler. The samples are not intended to illustrate real-world applications but rather the kinds of implementation issues web programmers face. (1) Processing User Input on the Server This sample page implements two textboxes, a listbox, and button. The user enters numbers in two textboxes, selects an arithmetic operation, clicks the button to post the form, and then server script performs the operation on the numbers and shows the result. The page also preserves the data the user entered when the page is regenerated after the post. Below is a version of this page implemented using traditional ASP programming:
<%
Dim Result, Operation
Dim Value1, Value2
Dim HaveResult
Value1 = 1
Value2 = 1
HaveResult = False
If Reguest.ServerVariables("REQUEST_METHOD") = "POST" Then
Value1 = CInt(Request.Form("text1"))
Value2 = CInt(Request.Form("text2"))
Op = CInt(Request.Form("select3"))
HaveResult = True
Select Case Op
Case 10:
Result = Value1 + Value2
Operation = "plus"
Case 20:
Result = Value1 - Value2
Operation = "minus"
Case 30:
Result = Value1 / Value2
Operation = "divided by"
Case 40:
Result = Value1 * Value2
Operation = "times"
End Select
End If
%>
<form method=POST>
Number 1:<input type=text name=text1
value="<%=Value1%>"><br>
Number 2:<input type=text name=text2 value="<%=Value2%>">
<select name=select3>
<option value=10 <% If Op = 10 Then Response.Write "SELECTED"
%>>Add</option>
<option value=20 <% If Op = 20 Then Response.Write "SELECTED"
%>>Subtract</option>
<option value=30 <% If Op = 30 Then Response.Write "SELECTED"
%>>Divide</option>
<option value=40 <% If Op = 40 Then Response.Write "SELECTED"
%>>Multiply</option>
</select><br>
<input type=submit value="Submit">
<%
If HaveResult Then
Response.Write("<p>" & Value1 & Operation & Value2 & "is" &
Result & "</p>")
End If
%>
</form>
To a designer familiar with conventional programming languages like Visual Basic or Java, this simple application appears confusing. To understand how to build a page like this, the developer is required to have a deep level of understanding about the interaction between the web server and browser and how HTML forms posting works. This programming model also cannot be easily represented in a visual rapid application development model, which leaves the developer hand-coding the page. Compare this to the same sample created with the scripting object model using DTCs:
<SCRIPT RUNAT=SERVER LANGUAGE=VBSCRIPT>
Sub thisPage_onenter ()
If thisPage.firstEntered Then
TextBox1.value = 1
TextBox2.value = 1
ListBox1.addItem "Add", 10
ListBox1.addItem "Subtract", 20
ListBox1.addItem "Divide", 30
ListBox1.addItem "Multiply", 40
ListBox1.selectByValue (10)
End If
End Sub
Sub Button1_onclick
Dim Result
Dim Value1, Value2
Value1 = CInt(TextBox1.value)
Value2 = CInt(TextBox2.value)
Select Case CInt(ListBox1.getValue())
Case 10:
Result = Value1 + Value2
Operation = "plus"
Case 20:
Result = Value1 - Value2
Operation = "minus"
Case 30:
Result = Value1 / Value2
Operation = "divided by"
Case 40:
Result = Value1 * Value2
Operation = "times"
End Select
Label1.setCaption(Value1 & Operation & Value2 & "is" &
Result)
End Sub
</SCRIPT>
Number 1:
[TEXT BOX1]
<br>
Number 2:
[TEXT BOX2]
[MENU]
<br>
[SUBMIT BUTTON]
<p>
[LABEL1]
</p>
The above sample may be quickly created by dragging a few controls into the editor and creating two event handlers--thisPage_onenter, which is fired when the user first navigates to the ASP page, and Button1_onclick. (2) Navigating to a Server Method on a Page The script fragments below show a conventional way of passing information to a server page by building a query string into the URL passed to the server:
PAGE1.ASP:
<%
Response.Write ("<A
HREF=""page2.asp?function=ProcessQuery1&parm1=" & parm1 &
"&parm2=" & parm2 & "">Start Query 1</A>")
Response.Write ("<A
HREF=""page2.asp?function=ProcessQuery2&parm1=" & parm3 &
"">Start Query 2</A>")
%>
PAGE2.ASP
<%
parm1 = Request.QueryString ("parm1")
parm2 = Request.QueryString ("parm2")
func = Request.QueryString ("function")
If func = "ProcessQuery1" Then
`code for the first operation
Else
`code for the second operation
End If
%>
This process may be quickly complicated as the number of possible operations and parameters increases. Through the Page object, the scripting object model provides a general-purpose way of publishing methods on a page so they can be invoked from client script on the current page or on other pages that reference the current page. The Page Object DTC provides a graphical way to publish methods using the Page object. The script fragments below show the same functionality implemented using the Page Object:
PAGE1.ASP:
<%
Response.Write ("<A
HREF=`Javascript:page2.navigate.ProcessQuery1 (parm1,
parm2)`>Start Query 1</A>")
Response.Write ("<A
HREF=`Javascript:page2.navigate.ProcessQuery2 (parm3) `>Start
Query 2</A>")
%>
PAGE2.ASP
<SCRIPT RUNAT=SERVER LANGUAGE=VBSCRIPT>
Sub ProcessQuery1 (parm1, parm2)
`code for first operation
End Sub
Sub ProcessQuery2 (parm1)
`code for second operation
End Sub
</SCRIPT>
The two methods on PAGE2 were published using the Page Object DTC, and a reference to PAGE2 was made from PAGE1 also using the Page Object DTC, to make those methods available in the SOM on PAGE1. The resulting code is simpler and far more readable than in the first example because it uses a more familiar programming model. (3) Remote Execution of a Server Method Another example is remote scripting. The Page object allows a developer to publish a method on a page that can be called synchronously or asynchronously from the client without posting a form. This allows a web page to remain live in the browser while a script fiction on the server is called and returns a value. The call can be synchronous; blocking until the remote call completes, or a callback function can be provided to process the function's return value asynchronously. Remote method calls can save bandwidth and reduce server load by avoiding the cost of regenerating the entire page after a post and sending it to the browser. The sample below shows an asynchronous remote scripting call that passes a user name to a server script function that returns the corresponding user id. A callback function processes the return value and navigates to a members page if the user id is valid.
<%
Function Lookup (name)
Lookup = dbLookupUser (name)
End Function
%>
<SCRIPT>
function ProcessResult (rscb)
{
if (rscb.return_value == -1)
alert("You do not have a valid user id.")
else
Members.navigate.LoginUser(rscb.return_value);
}
</SCRIPT>
<INPUT TYPE=TEXT NAME=UserName VALUE="">
<BUTTON NAME=Enter VALUE="Enter"
ONCLICK=`thisPage.execute.Lookup (thisForm.UserName.value,
ProcessResult)`>
(4) Sharing State Between Client and Server Earlier examples addressed the issues of state management by demonstrating that the scripting object model objects manage their own state. To maintain state between objects, an additional approach can be used. The ASP script fragment below shows how this may be done using a hidden form element. The page initializes a value and then increments it by one each time the user clicks a button.
<%
Dim Value1
If Request.ServerVariables ("REQUEST_METHOD") = "POST" Then
Value1 = Request.Form("Value1")
Value1 = Value1 + 1
Else
Value1 = 0
End If
%>
<FORM NAME=MyForm METHOD=POST>
<INPUT TYPE=HIDDEN NAME=Value1 VALUE="<%=Value1 %>">
Value = <%=Value1%><br>
<INPUT TYPE=SUBMIT VALUE="Submit">
The scripting object model (SOM) makes state management easier by providing a way to publish page properties through the Page object. Using the Page Object DTC the developer can publish a property, which can then be accessed using "get" and "set" methods on the Page Object. The sample below shows the same functionality implemented using the SOM:
<SCRIPT LANGUAGE=VBSCRIPT RUNAT=SERVER>
Sub thisPage_onenter
If thisPage.firstEntered Then
thisPage.setValue1 (0)
End If
End Sub
Sub Button1_onclick
thisPage.setValue1(thisPage.getValue1 () + 1)
End Sub
</SCRIPT>
Value = <%=thisPage.getValue1 () %><br>
<INPUT TYPE=SUBMIT VALUE="Submit">
The remote scripting components of the Scripting Library include a set of client script functions and objects that can be used in conjunction with the Page Object DTC or separately. When used with the Page Object DTC, remote scripting functions are published as methods of the execute object. G. Construction of Objects The Scripting Object Model (SOM) provides an event-based execution model for ASP pages. As discussed above, while in actuality, the page is executed serially as any other ASP page, the SOM provides a framework for programming to an event-based model. At a high-level, the execution and eventing sequence is similar to the DHTML browser execution sequence. Objects on the page are constructed and initialized. An onenter event is fired to indicate that the page is loaded and all objects are ready to be scripted. This is an ideal place to initialize variables and objects. After the onenter event is fired, execution is transferred to an entry-point or event-handler. By default, the content portion of the page will be executed which is equivalent to invoking the show entry-point. In many cases, execution will transfer to a server-side handler as a result of a button click or some other user action. An onshow event is fired just prior to executing the content portion of the page. This is an ideal place to set the final state for any objects just prior to them rendering their HTML output. After the content portion of the page is executed, an onexit event is fired to indicate the page is unloading. 1. Execution and Event Sequence a) Object Construction Phase Each object is constructed. This is accomplished by executing all JScript functions which conform to the following naming convention, "xxxx_ctor". The DTCs generate a _ctor function for the runtime object they represent. One implementation executes each _ctor in the order it appears on the page. An object constructor should be self-contained, and should not expect any other object to have already been constructed. b) Construction of the "thisPage" Object The first object constructed will be a SOM Object named thisPage. This object provides properties, methods, and events that comprise the Scripting Object Model. Other objects will use the thisPage object for state services, event notification, and other purposes. c) Registering an Initialization Function The constructor function of each object will register an initialization function with the thisPage object via the advise method. The initialization functions will be invoked during the initialization phase, after all object constructors have been invoked. A pointer to the initialization function is provided as a parameter to the constructor, and the function implementation is generated by a DTC based on the properties set at design-time. A Recordset object will register its initialization function with a higher priority than other objects. This ensures that the Recordset objects will be initialized before any other objects that may depend on the Recordset for databinding. d) Registering Default EventHandlers The constructor function for most objects may register any default EventHandlers for the object. A default EventHandler is a method which conforms to the naming convention "object_event". The Recordset object will defer registration of its default EventHandlers until the end of the initialization phase (with the exception of the onbeforeopen event). This ensures that the default Recordset EventHandlers will not be fired until all other objects have been both constructed and initialized. e) Object Initialization Phase The registered initialization functions will be invoked in this phase. The functions are invoked in priority order, with functions of same priority being invoked in the order registered. f) Recordset Initialization The Recordset initialization functions are registered with a high priority, such that all Recordsets will be initialized before any other objects. The initialization function of the Recordset will setup the connection and command for the Recordset based upon settings chosen via the Recordset DTC property pages at design-time. If the Recordset is set to autoopen or if the Recordset was left open on the previous roundtrip to this same page, the Recordset will be opened at this point. To prevent a Recordset from being opened during this initialization phase, the autoopen flag should be disabled in the DTC property page, and the Recordset should be explicitly closed prior to exiting the page. The thisPage_onexit handler is a good place for closing Recordsets. g) Object Initialization Object initialization functions are registered with a neutral priority, and will be invoked after high priority initialization functions, such as those for the Recordset. Objects which are set to databind to a Recordset, will use the advise method of the appropriate Recordset to register a handler on the onrowenter event and possible the onbeforeupdate event. The onrowenter handler will be used to bind data from the Recordset into the object. The onbeforeupdate handler will be used to bind data from the object into the Recordset. If the Recordset is already open when an object registers an onrowenter handler, then that handler will be invoked immediately in order to bind the object to the current row of the Recordset. Following the registration of databinding handlers, the object will restore any state that has been roundtripped back to this page. h. Summary The programming model and embodiments thereof in various forms provides a number of advantages to the various users. For example, the system provides an easier way for developers to conceptualize a site. Also, in targeting an IE 4 DHTML client, a programmer can run VB-like forms, can write code for the end client and can provide an interactive environment for the end client. Further, supplied forms may be supported by objects and script behind the form. This form then can execute on a server in a linear sequence. While the above embodiments considered with reference to design-time controls, alternative controls may also be used. In particular, because a design-time control can be made part of a page, and therefore inadvertently deleted by a developer, an alternative embodiment of the invention uses separate pages for the control and property pages for each object. These pages would be inaccessible by developers by placing them in an alternate directory or by making them read-only. Depending on its programming, each design-time control may include non-ActiveX scripts as well. Therefore, by instantiating the design-time control into a web page, the resulting run-time code may include both the ActiveX implementation as well as the non-ActiveX counterpart. Non-ActiveX scripts may include, for example, JAVA.RTM. (by Sum Microsystems). Other non-ActiveX scripts may also be included. It will be apparent to those skilled in the art that application of the present invention is not restricted to the Internet. It is also envisioned that the techniques of the present invention apply to any network using HTTP, including HTTPS-compliant networks, intranets and extranets. It is further envisioned that the techniques of the present invention apply in any text-authoring context where complex scripts require detailed knowledge of databases as well as related pages. For example, embodiments of the present invention contemplate the use of the programming object modeling system in conjunction with other systems including spreadsheets and other related environments. Further, the present invention may also be implemented in a peer-to-peer computing environment or in a multi-user host system with a mainframe or a minicomputer. Thus, the computer network, in which the invention is implemented, should be broadly construed to include any client/server computer network from which a client can retrieve a remote document on a server (even if that document is available on the same machine or system). In the foregoing specification, the present invention has been described with reference to specific exemplary embodiments thereof. Although the invention has been described in terms of a preferred embodiment, those skilled in the art will recognize that various modifications, embodiments or variations of the invention can be practiced within the spirit and scope of the invention as set forth in the appended claims. All are considered within the sphere, spirit, and scope of the invention. The specification and drawings are, therefore, to be regarded in an illustrated rather than restrictive sense. Accordingly, it is not intended that the invention be limited except as may be necessary in view of the appended claims.
|
Same subclass Same class | ||||||||||