U.S. patent application number 10/990152 was filed with the patent office on 2006-05-18 for methods and systems for server side form processing.
This patent application is currently assigned to Microsoft Corporation. Invention is credited to Ranjan Aggarwal, David Airapetyan, Brian G. O'Connor, Prakash Sikchi.
Application Number | 20060106858 10/990152 |
Document ID | / |
Family ID | 36387698 |
Filed Date | 2006-05-18 |
United States Patent
Application |
20060106858 |
Kind Code |
A1 |
Sikchi; Prakash ; et
al. |
May 18, 2006 |
Methods and systems for server side form processing
Abstract
Various embodiments can efficiently utilize form server
resources by, in at least some embodiments, acting only on one tree
during the form editing process. Various embodiments can act on a
form's data and not necessarily a representation of the form's
view. The described embodiments can support various different
presentation formats.
Inventors: |
Sikchi; Prakash; (Issaquah,
WA) ; Aggarwal; Ranjan; (Redmond, WA) ;
O'Connor; Brian G.; (Seattle, WA) ; Airapetyan;
David; (Kirkland, WA) |
Correspondence
Address: |
LEE & HAYES PLLC
421 W RIVERSIDE AVENUE SUITE 500
SPOKANE
WA
99201
US
|
Assignee: |
Microsoft Corporation
Redmond
WA
|
Family ID: |
36387698 |
Appl. No.: |
10/990152 |
Filed: |
November 16, 2004 |
Current U.S.
Class: |
1/1 ;
707/999.102 |
Current CPC
Class: |
G06F 40/174
20200101 |
Class at
Publication: |
707/102 |
International
Class: |
G06F 17/00 20060101
G06F017/00; G06F 7/00 20060101 G06F007/00 |
Claims
1. A method comprising: receiving, with a form server, a request
that embodies form changes; loading previous data that corresponds
to the form, into a data tree; operating on the data tree
sufficient to incorporate the changes; after all of the changes are
incorporated on the data tree, instantiating, for the first time
relative to the changes that were just incorporated, a view tree
based on the data tree; rendering a markup representation of the
view tree; and returning the markup representation to a user agent
from which the request was received.
2. The method of claim 1, wherein said act of operating comprises
mapping at least one identifier associated with a form control onto
a corresponding node in the data tree and performing one or more
operations on data associated with the form control.
3. The method of claim 1, wherein the act of receiving is performed
by receiving an event log that embodies the order in which form
changes were made.
4. The method of claim 1, wherein the act of receiving is performed
by receiving an event log that embodies the order in which form
changes were made, and wherein the act of operating on the data
tree comprises serially processing each entry in the event log and,
responsively, operating on the data tree.
5. The method of claim 1, wherein the act of receiving is performed
by receiving an event log that embodies the order in which form
changes were made, and wherein the event log comprises a descriptor
field that contains a descriptor or command for particular user
editing actions.
6. The method of claim 1, wherein the act of receiving is performed
by receiving an event log that embodies the order in which form
changes were made, and wherein the event log comprises: a
descriptor field that contains a descriptor or command for
particular user editing actions; and a control ID field that
contains values associated with a control identifier for an
associated descriptor.
7. The method of claim 1, wherein the act of receiving is performed
by receiving an event log that embodies the order in which form
changes were made, and wherein the event log comprises: a
descriptor field that contains a descriptor or command for
particular user editing actions; a control ID field that contains
values associated with a control identifier for an associated
descriptor; and a parameters field that contains parameters
associated with a particular user action.
8. The method of claim 1, wherein the act of receiving is performed
by receiving an event log that embodies the order in which form
changes were made, and wherein the event log comprises: a
descriptor field that contains a descriptor or command for
particular user editing actions; a control ID field that contains
values associated with a control identifier for an associated
descriptor; a parameters field that contains parameters associated
with a particular user action; and a value field for maintaining
entries associated with new values for a control.
9. The method of claim 1, wherein the act of receiving is performed
by receiving an event log that embodies the order in which form
changes were made, and wherein the event log comprises: a
descriptor field that contains a descriptor or command for
particular user editing actions; a control ID field that contains
values associated with a control identifier for an associated
descriptor; a parameters field that contains parameters associated
with a particular user action; a value field for maintaining
entries associated with new values for a control; and a new control
ID field associated with new controls that might be created by the
user.
10. The method of claim 1, wherein the act of instantiating is
performed by applying a transform to the data tree.
11. The method of claim 1, wherein at least one of the changes
comprises a structural change to the form.
12. One or more computer-readable media embodying computer-readable
instructions thereon which, when executed by one or more
processors, cause the one or more processors to implement a method
comprising: receiving, with a form server, a request that embodies
form changes, wherein the request comprises an event log that
embodies the order in which form changes were made; loading
previous data that corresponds to the form, into a data tree;
operating on the data tree sufficient to incorporate the changes;
instantiating a view tree based on the data tree; rendering a
markup representation of the view tree; and returning the markup
representation to a user agent from which the request was
received.
13. The one or more computer-readable media of claim 12, wherein
said act of operating comprises mapping at least one identifier
associated with a form control onto a corresponding node in the
data tree and performing one or more operations on data associated
with the form control.
14. The one or more computer-readable media of claim 12, wherein
the act of operating on the data tree comprises serially processing
each entry in the event log and, responsively, operating on the
data tree.
15. The one or more computer-readable media of claim 12, wherein
the event log comprises a descriptor field that contains a
descriptor or command for particular user editing actions.
16. The one or more computer-readable media of claim 12, wherein
the event log comprises: a descriptor field that contains a
descriptor or command for particular user editing actions; and a
control ID field that contains values associated with a control
identifier for an associated descriptor.
17. The one or more computer-readable media of claim 12, wherein
the event log comprises: a descriptor field that contains a
descriptor or command for particular user editing actions; a
control ID field that contains values associated with a control
identifier for an associated descriptor; and a parameters field
that contains parameters associated with a particular user
action.
18. The one or more computer-readable media of claim 12, wherein
the event log comprises: a descriptor field that contains a
descriptor or command for particular user editing actions; a
control ID field that contains values associated with a control
identifier for an associated descriptor; a parameters field that
contains parameters associated with a particular user action; and a
value field for maintaining entries associated with new values for
a control.
19. The one or more computer-readable media of claim 12, wherein
the event log comprises: a descriptor field that contains a
descriptor or command for particular user editing actions; a
control ID field that contains values associated with a control
identifier for an associated descriptor; a parameters field that
contains parameters associated with a particular user action; a
value field for maintaining entries associated with new values for
a control; and a new control ID field associated with new controls
that might be created by the user.
20. The one or more computer-readable media of claim 12, wherein
the act of instantiating is performed by applying a transform to
the data tree.
21. The one or more computer-readable media of claim 12, wherein at
least one of the changes comprises a structural change to the
form.
22. A method comprising: receiving, with a form server, a request
that embodies form changes, wherein the request comprises an event
log that embodies the order in which form changes were made;
loading previous data that corresponds to the form, into a data
tree; operating on the data tree sufficient to incorporate the
changes; instantiating a view tree based on the data tree;
rendering a markup representation of the view tree; and returning
the HTML representation to a user agent from which the request was
received.
23. The method of claim 22, wherein said act of operating comprises
mapping at least one identifier associated with a form control onto
a corresponding node in the data tree and performing one or more
operations on data associated with the form control.
24. The method of claim 22, wherein the act of operating on the
data tree comprises serially processing each entry in the event log
and, responsively, operating on the data tree.
25. The method of claim 22, wherein the event log comprises a
descriptor field that contains a descriptor or command for
particular user editing actions.
26. The method of claim 22, wherein the event log comprises: a
descriptor field that contains a descriptor or command for
particular user editing actions; and a control ID field that
contains values associated with a control identifier for an
associated descriptor.
27. The method of claim 22, wherein the event log comprises: a
descriptor field that contains a descriptor or command for
particular user editing actions; a control ID field that contains
values associated with a control identifier for an associated
descriptor; and a parameters field that contains parameters
associated with a particular user action.
28. The method of claim 22, wherein the event log comprises: a
descriptor field that contains a descriptor or command for
particular user editing actions; a control ID field that contains
values associated with a control identifier for an associated
descriptor; a parameters field that contains parameters associated
with a particular user action; and a value field for maintaining
entries associated with new values for a control.
29. The method of claim 22, wherein the event log comprises: a
descriptor field that contains a descriptor or command for
particular user editing actions; a control ID field that contains
values associated with a control identifier for an associated
descriptor; a parameters field that contains parameters associated
with a particular user action; a value field for maintaining
entries associated with new values for a control; and a new control
ID field associated with new controls that might be created by the
user.
30. The method of claim 22, wherein the act of instantiating is
performed by applying a transform to the data tree.
31. The method of claim 22, wherein at least one of the changes
comprises a structural change to the form.
32. A method comprising: receiving, with a form server, a request
that embodies form changes, wherein the request comprises an event
log that embodies the order in which form changes were made;
loading previous data that corresponds to the form, into a data
tree; operating on the data tree sufficient to incorporate the
changes; returning, to a user agent from which the request was
received, with data that can be used by the user agent to render a
new form.
33. The method of claim 32, wherein said act of operating comprises
mapping at least one identifier associated with a form control onto
a corresponding node in the data tree and performing one or more
operations on data associated with the form control.
34. The method of claim 32, wherein the act of returning comprises
returning HTML data to the user agent, wherein the HTML data
comprises all of the HTML data that is to be used to render the
form.
35. The method of claim 32, wherein the act of returning comprises
returning only data associated with changes that have been made to
the form.
36. A system comprising: means for receiving, with a form server, a
request that embodies form changes, wherein the request embodies
the order in which form changes were made; means for loading
previous data that corresponds to the form, into a data tree; means
for operating on the data tree sufficient to incorporate the
changes; and means for returning, to a user agent from which the
request was received, with data that can be used by the user agent
to render a new form.
37. The system of claim 36, wherein said means for returning
comprises means for providing data that can be used to render the
form on different types of devices.
38. The system of claim 36, wherein said means for returning
comprises means for providing data that can be used to render the
form using different presentation technologies.
39. The system of claim 36, wherein said means for returning
comprises means for providing data that can be used to render the
form on different types of devices and using different presentation
technologies.
40. The system of claim 36, wherein said request comprises log
means.
Description
TECHNICAL FIELD
[0001] This invention relates to methods and systems for exchanging
and rendering forms on computing devices.
BACKGROUND
[0002] Conventional form-rendering systems, such as those that
render HTML forms, utilize a simple protocol to communicate between
a client device on which the form is rendered and manipulated by a
user, and a server that processes and provides data for rendering
on the client device. More specifically, client devices in this
type of environment typically send data to the server in the form
of name-value pairs. The name portion of the name-value pair
corresponds to a particular control in the form (such as a field in
which the user might enter their name or address), and the value
portion of the name-value pair corresponds to data that appears in
a control.
[0003] Typically, the server has been responsible for figuring out
which data has changed and then, responsively, taking the
appropriate action such as modifying the form, and then returning
HTML data to the client device which can then be rendered for the
user.
[0004] This simple protocol leaves much to be desired and has many
shortcomings not the least of which include the inability to
provide or support a rich, dynamic user experience, the inability
to scale in a desirable manner, and taxing server resources.
SUMMARY
[0005] Various embodiments can efficiently utilize form server
resources by, in at least some embodiments, acting only on one tree
during the form editing process. Various embodiments can act on a
form's data and not necessarily a representation of the form's
view. The described embodiments can support various different
presentation formats
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 illustrates an exemplary client/server computing
environment in connection with which various embodiments can be
implemented.
[0007] FIG. 2 illustrates an exemplary form that is described in
the context of one or more embodiments.
[0008] FIG. 3 illustrates an exemplary event log in accordance with
one embodiment.
[0009] FIG. 4 is a flow diagram that describes steps in the method
in accordance with one embodiment.
[0010] FIG. 5 is a flow diagram that describes steps in the method
in accordance with one embodiment.
[0011] FIG. 6 illustrates an exemplary computing device that can be
used to implement one or more of the described embodiments.
DETAILED DESCRIPTION
[0012] Overview
[0013] Various embodiments described below can support a richly
dynamic form environment that permits editing on the client side
and can alleviate many of the server-imposed processing
complexities that have existed in the past. In at least some
embodiments, complex editing scenarios permit users to make complex
editing changes on a form, and have those editing changes captured
and rendered on the client side for later communication to the
server. Particular aspects of at least some of the embodiments
described below can permit scalability, and can, in at least some
instances, be employed in the context of a wide variety of browsers
having different levels of capability, e.g. "thin" and "thick"
browsers.
[0014] Exemplary Computing Environment
[0015] Preliminarily, the embodiments about to be described can be
utilized in connection with a client/server computing environment,
such as the one shown generally at 100. Environment 100 includes,
in this example, a client computing device 102 that communicates
with one or more servers 104 which, in this example can comprise
form servers.
[0016] In the illustrated and described embodiment, computing
device 102 communicates with server(s) 104 via a communication
network 106, such as an intranet or the Internet. Computing device
102 comprises at least one or more processors 108, an operating
system 110, one or more computer-readable media 112 and one or more
applications 114 embodied on the computer-readable media 112. A
more detailed description of an exemplary computing device appears
at the end of this document under the heading "Exemplary Computing
Device".
[0017] In this particular example, one of application 114 comprises
a user agent such as a web browser. The user agent allows a user to
interact with a form that is provided by form server 104. In the
context of a user agent that comprises a web browser, the user
agent enables a user to access the Internet and interact with form
server 104 to receive and edit a form.
[0018] It is to be appreciated and understood that other well-known
computing systems, environments, and/or configurations can be
utilized in connection with the embodiments that are about to be
described. For example, such computing systems, environments and/or
configurations can include, without limitation, personal computers,
server computers, hand-held or laptop devices, multiprocessor
systems, microprocessor-based systems, programmable consumer
electronics, network PCs, minicomputers, mainframe computers,
distributed computing environments that include any of the above
systems or devices, and the like.
[0019] The embodiments about to be described can be described in
the general context of, or implemented with, computer-executable
instructions, such as program modules, executed by one or more
computers or other devices. Generally, program modules include
routines, programs, objects, components, data structures and etc.
that perform particular tasks or implement particular abstract data
types. The functionality of the program modules may be combined or
distributed in various embodiments, including those described
below.
[0020] These computer-executable instructions can comprise or be
embodied on computer-readable media 112 which can comprise, for
example, computer storage media and communication media. Computer
storage media includes volatile and nonvolatile, removable and
non-removable media implemented in any method or technology for
storage of information. This stored information can comprise
computer-readable instructions, data structures, program modules,
and other data. Computer storage media comprise, by way of example,
RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM,
digital versatile disks (DVDs) or other optical storage, magnetic
media storage devices, or any other medium that can be used to
store the desired information.
[0021] Communication media typically embodies computer-readable
instructions, data structures, program modules, or other data in a
modulated data signal (e.g., a carrier wave or other transport
mechanism) and includes any information delivery media. The term
"modulated data signal" means a signal that has one or more of its
characteristics set or changed in such a manner as to encode
information in the signal. Communication media can comprise, for
example, wired media, such as a wired network or direct-wired
connection, and wireless media, such as acoustic, RF, infrared, and
other wireless media. Combinations of any of the above can also be
included within the scope of computer-readable media.
[0022] Capturing User Form Modifications
[0023] In at least one embodiment, when a user interacts with a
particular form, a user agent executing on the client device keeps
track of the changes made to the form, as well as the order of the
changes or events that are generated by the user's interaction. The
user agent can then, periodically, communicate those changes, in
the order that the changes occurred, to the appropriate form server
for processing. In at least some embodiments, the user agent can
make the changes directly on the form that the user interacts with.
For example, if a user manipulates the structure of the form, at
least some user agents can implement the structural change and
then, at some later time communicate those changes to the server
for processing.
[0024] When the form server receives the changes, the server can
then process the changes and send appropriate data to the client
device for rendering. More specifically, when the server receives
the data that describes the user-made changes and the order in
which the changes were made to a form served up by the server, the
server can process the data to produce processed data that can be
sent to the client device and used to render an updated form on the
client device. Examples of how this can be done are described
below.
[0025] In at least one embodiment, only the changes are sent to the
server, rather than all of the data associated with the entire form
and its controls. In turn, server resources and overhead are
conserved because the server does not have to process data that is
unassociated with the changes or modifications that the user made
to the form.
[0026] As an example, consider FIG. 2 which shows an exemplary form
200 in the form of a web form that a user might access at a web
site when, for example, attempting to place an order for a
particular product. In this example, form 200 includes a number of
controls, one of which is indicated at 202 in the form of a "Date
Ordered" field in which the user can enter the date that a
particular order is submitted. Assume also that the user has used
this web site before and is known (along with their pertinent
billing information) to the site. In this example, the only new
information that might be entered in the form is information that
is entered into the "Reference No.", "Date Ordered" and "Date
Requested" fields. That is, assume that form 200 populates the form
with the information that it already maintains for a particular
user and that when the web site processes a particular form, it
knows who sent the form.
[0027] In accordance with at least one embodiment, only the form
changes (and the order in which they occur) are communicated to the
server. That is, there are a number of controls whose associated
information does not change. In this case, information associated
with those controls is not communicated to the server. Hence, in
this example, only information associated with the controls
"Reference No.", "Date Ordered" and "Date Requested" is eventually
communicated to the server.
[0028] Consider further that the user wishes to modify the
structure of the form in some way. For example, assume that the
user wishes to insert an additional address control (e.g. "Address
3"). In the present embodiment, the user can manipulate the
structure of the form and have those manipulations tracked and
implemented by the user agent which, in this example, is a web
browser. Eventually, as will be discussed, those manipulations as
well as other changes to the form can be articulated to the server
so that the server can provide updated data back to the client
device for rendering.
[0029] The Event Log
[0030] Although the user agent can maintain the user-induced
modifications of a particular form in any suitable structure, in at
least one embodiment, the agent maintains an event log which
maintains a list of changes or events that have occurred.
Periodically, the user agent articulates the event log to the
server so that the server can process the event log as described in
more detail below. By maintaining the list of changes and/or events
on the client device, the client device can implement the changes
in a generally contemporaneous manner to provide the user with
almost immediate feedback, without necessarily having to
communicate with the server to affect the changes. In this way, the
user can see their changes implemented without the changes being
affected by the communication latency between the client device and
the server. In addition, because the changes or events can be
tracked and then periodically provided to the server, the server is
not called upon to process, in a piecemeal manner, every single
change that the user makes every time they make a change or
generate an event. Hence, this approach can conserve server
processing resources.
[0031] In the illustrated and described embodiment, the event log
is structured in a format that is powerful and extensible enough to
support arbitrary editing actions. This enables the browser, in at
least some instances, to support such editing actions without
having to communicate with the server. In the illustrated and
described embodiment, the event log can naturally scale to the
capabilities of a particular browser. For browsers that are less
functional (i.e. "thin" browsers), there is typically more frequent
communication with a particular server. An example of this is given
below. For browsers that are more functional, there is typically
less frequent communication with a particular server and hence, the
event logs can be longer.
[0032] FIG. 3 illustrates an exemplary event log in accordance with
one embodiment, generally at 300. In this example, the event log
contains a number of fields. For example, a descriptor field 302
contains a descriptor or command for a particular action that a
user takes. Examples of descriptors include, by way of example and
not limitation, the following: TABLE-US-00001
XCollectionInsert(containerId, Performs an insertion of a
beforeSiblingId, newControlId) new control.
XCollectionInsertBefore(containerId, Performs an insertion of a
beforeSiblingId, newControlId) new control.
XCollectionInsertAfter(containerId, Performs an insertion of a
afterSiblingId, newControlId) new control.
XOptionalInsert(containerId, Performs an insertion of a
beforeSiblingId, newControlId) new control.
XCollectionRemove(controlId) Removes a single item of a repeating
collection. XCollectionRemoveAll(controlId) Removes all items of a
repeating collection. XOptionalRemove(controlId) Removes an
optional item. VerifyChange(controlId, Implicit Change: verifies
expectedValue) that a client-side change that was caused by a side-
effect was also triggered on the server.
VerifyValidation(controlId, Declarative validation: expectedErrors)
verifies that a validation error triggered by the client was also
triggered by the server.
[0033] A control ID field 304 contains values associated with the
identifier for a control to which the editing action is to be
applied. A parameters field 306 includes the parameters for a
particular editing action. For example, some editing actions may
require a text string to be inserted for a particular editing
action. In this case, the parameters field would include a text
string value. Another example would be a button click, in which
case the parameters would include the button id and the button's
current container. Yet another example would be an insertion of a
new control, where the parameters would include a container for
insertion, relative sibling and a name for a new control.
[0034] A value field 308 maintains entries associated with new
control values. This assists the server in maintaining the state of
the controls throughout a user's editing actions. A new control ID
field 310 is provided and, if new controls are created by the user
because of an editing action, holds an identifier for the new
control. This permits subsequent entries in the event log to refer
to the new control(s).
[0035] It is to be appreciated and understood that the exemplary
event log illustrated in FIG. 3 is not to be used to limit
application of the claimed subject matter. Rather, other event logs
can be utilized without departing from the spirit and scope of the
claimed subject matter.
[0036] Exemplary Method
[0037] FIG. 4 is a flow diagram that describes steps in a method in
accordance with one embodiment. The method can be implemented in
connection with any suitable hardware, software, firmware or
combination thereof. In but one embodiment, and as diagrammatically
indicated, some aspects of the described method can be implemented
in connection with a suitably configured user agent such as a web
browser, and other aspects of the described method can be
implemented in connection with a suitably configured form
server.
[0038] Step 400 receives user input relative to a rendered form.
The user input can be received in any suitable form. For example,
the user may type a text string into a field associated with a
particular control, the user can click on a particular control and
the like. Step 402 computes changes to the form associated with the
received input and implements the changes on the form. The changes
can involve, for example, modifications to the controls or data
fields associated with the control or, in at least some
embodiments, can involve changing, in some way, the structure of
the form. For example, the user may wish to add a column or row to
a particular table on the form. Alternately or additionally, the
user may wish to add a button or some other type of control to a
particular form. In this case, step 402 would compute the form
change and implement the change on the form.
[0039] Step 404 makes an entry in an event log that pertains to the
form changes spawned by the user's input. It is to be appreciated
and understood that the entries in the event log are made serially
and track the input provided by the user. That is, the entries in
the event log capture the nature of the changes and the order in
which the changes occur. But one example of an event log is
provided above in FIG. 3.
[0040] Step 406 ascertains whether the event log should be reported
to the server. Any suitable criteria can be utilized to ascertain
whether the event log should be sent to the server. For example,
some browsers may have a practical size limit on the size of the
event log. In this case, when the size of the event log reaches
some threshold, it can be sent to the server. Alternately or
additionally, some browsers may be "thin" browsers in the sense
that they need to communicate with the server frequently because,
for example, they may not be able to implement certain changes that
the user desires to make. For example, some browsers may not be
able to make structural changes to a particular form. In this case,
these thin browsers can maintain an event log and, when a desired
user action cannot be performed by the browser, the browser can
send the event log, along with an indication of the desired action
to the server. Alternately or additionally, there may be a lack of
sufficient information on the client device such that the event log
should be reported to the server. For example, a user may trigger
an action that requires a database lookup; or a user may trigger a
calculation for which all data is not available. Alternately or
additionally, the user may make a change to the form that radically
alters the presentation in which case some browsers may not be able
to implement the change. Alternately or additionally, in some
cases, browsers may not be able to implement advanced
functionality, such as spellchecking and the like in which case,
the event log might be reported to the server.
[0041] If, depending on whatever criterion is used, the event log
need not be reported to the server, then the method returns to step
400. If, on the other hand, the event log is to be reported to the
server, then the method reports the event log to the server
(following the "Yes" branch in the figure).
[0042] Step 408, performed by the server, receives the event log
that is reported from the browser. Step 410 processes the event log
and step 412 returns data to the browser that can be used to render
the form.
[0043] The event log can be processed by the server in any suitable
way. For example, in one embodiment, when the server receives the
event log, it can return back HTML to the browser that is utilized
to render the view that the user sees. Alternately, the server can
process the event log and return back data for the appropriate
controls that are to be rendered by the browser. For example, in
the case of a "thin" browser, the server might return all of the
HTML that is to be processed and used to render the form on the
client device. Alternately, for robust browsers that possess robust
functionality, the server may just return the appropriate data
associated with the appropriate controls that are to be
rendered.
[0044] From a practical standpoint and in connection with one
embodiment, once the server receives the event log, it first parses
the event log into individual events and invokes the appropriate
form for each event. In this embodiment, the forms are based on XML
data. Accordingly, the server instantiates the form's XML DOM in
memory, and then processes each event. For each event, the control
has an identification or ID (as noted in the event log above). The
control ID for a particular event is processed and mapped onto a
corresponding node in the XML DOM. The server then performs the
operation indicated in the event log entry. This provides modified
XML data which reflects the modifications made by the user.
[0045] When the processing is finished insofar as event log entries
are concerned, the resultant XML data can either be processed, as
by applying suitable transforms to the XML data, to recreate the
form view HTML which is sent to the browser (in the event of "thin
browsers"), or the actual data for the associated controls can be
sent to the browser (in the event of "thick" browsers).
[0046] Data-Centric XML Form Processing
[0047] In at least one embodiment, the form server can process the
XML data and implement the user's editing actions by acting
directly upon the data without having to instantiate and maintain
synchrony between two different trees--typically referred to as a
"view tree" and a "data tree". This constitutes an improvement over
past "two-tree" approaches by conserving server resources and
enhancing the flexibility of the system. Before considering the
inventive approach, consider the following.
[0048] Typically, using a two tree approach, when the server, in
this case an HTML form server, receives a request from a browser
that contains form edits, a view tree that corresponds to the form
is built in memory. The previous XML corresponding to the form is
then loaded into a data tree. The view tree is then populated with
the previous data values. Now, the previous values are compared
with the new values for each control from the request that was sent
by the browser. For each change that is found, the appropriate
control is notified and the change is processed. This can include
validating the values, invoking business logic, updating the data
tree and the like. If the data tree changes such that the control
needs to be updated, then the view tree is updated.
[0049] After all of this processing, an HTML representation of the
view tree is rendered and sent as a response to the browser.
[0050] This approach can be inefficient in terms of utilization of
the server's resources. That is, by using two trees, each of the
trees has the editing actions performed on them. In addition,
certain features may be invoked in response to changes in the view
tree, while other changes may be invoked in response to changes in
the data tree. Further, this approach inextricably ties the logic
that might be invoked to a specific implementation or view of the
form. As will be appreciated by the skilled artisan, this gives
rise to inflexibilities insofar as presentation formats are
concerned.
[0051] In accordance with at least one embodiment, an approach is
adopted that eliminates the server's reliance on the view tree to
implement editing changes. In the inventive approach, form changes
are built, by the server, directly on the data itself. Because the
logic that is applied to the changes is written on the data rather
than on the HTML view, logic can be written to change the
representation of the data without having to rewrite the data. This
means that different presentation formats can be utilized which, in
turn, enhances the flexibility of the overall system. More
specifically, what this means is that the same form can run in
different presentation environments--such as desk top environments,
handheld device environments and the like. Furthermore, the same
form can potentially run on different presentation platforms, for
example, a browser versus a thick client versus a Powerpoint
Presentation. That is, in at least some embodiments, the form can
be rendered on different devices such as PDAs, telephones and the
like, or using different presentation technologies such as WordML,
XAML and the like.
[0052] In the illustrated and described embodiments, the
functionality described above and below can be implemented using
any suitable means. In at least some embodiments, such means
comprises software that can reside on a particular server or form
server.
[0053] FIG. 5 is a flow diagram that describes steps in a method in
accordance with one embodiment. The method can be implemented in
connection with any suitable hardware, software, firmware or
combination thereof. In but one embodiment, the method is
implemented in software on a suitably configured form server.
[0054] Step 500 receives a request from a user agent embodying form
changes. In but one embodiment, the user agent comprises a web
browser. The request from the user agent can assume any suitable
configuration. In but one embodiment, the changes are embodied in
an event log, such as the event log described above. It is to be
appreciated and understood, however, that the above-described event
log constitutes but one exemplary change-transportation mechanism.
As such, other transportation mechanisms can be utilized without
departing from the spirit and scope of the claimed subject
matter.
[0055] Step 502 loads previous XML data associated with the form
into a data tree, and step 504 processes the changes by operating
on the data tree. Notice in this embodiment, that the form changes
and edits are made by operating on only one tree.
[0056] In embodiments in which the form changes are transported to
the server in the form of an event log, step 504 can be performed
as follows. Each entry in the event log is serially processed in
the order in which it occurs. For each entry in the event log, this
may mean that the change is validated, business logic is invoked
and the like.
[0057] Step 506 ascertains whether there are any additional form
changes. In the event log embodiments, this step can be performed
by ascertaining whether there are any additional log entries. If
there are additional event log entries, then the method returns to
step 504. If, on the other hand, there are no additional changes to
be made, step 508 instantiates a view tree (also referred to as a
"control tree") based on the data tree. This step can be performed,
for example, by applying a suitable template or transform to the
data tree. Examples of templates can include, without limitation,
XSL transforms and the like.
[0058] Consider now the flexibility provided by step 508. Because
the above operations are performed on the data and not the view,
the transforms that can applied to the data tree can flexibly
accommodate different and diverse presentation environments.
[0059] Step 510 then renders an HTML representation of the view
tree and step 512 returns the HTML representation to the user
agent.
[0060] The above-describe approach can efficiently utilize server
resources by, in at least some embodiments, acting only on one tree
during the editing process. Additionally, because the described
approach acts on the data and not on the view (or in other words is
"data-centric"), various different presentation formats can be
supported which, in turn, greatly enhances the flexibility of the
system. Moreover, the described approach can seamlessly and
efficiently incorporate structural changes into a form in a manner
that the "two tree" approach simply can not.
[0061] Exemplary Computing Device
[0062] FIG. 6 shows an exemplary computing device that can be used
to implement the processes described above. Computing device 642
comprises one or more processors or processing units 644, a system
memory 646, and a bus 648 that couples various system components
including the system memory 646 to processors 644. The bus 648
represents one or more of any of several types of bus structures,
including a memory bus or memory controller, a peripheral bus, an
accelerated graphics port, and a processor or local bus using any
of a variety of bus architectures. The system memory 646 comprises
read only memory (ROM) 650 and random access memory (RAM) 652. A
basic input/output system (BIOS) 654, containing the basic routines
that help to transfer information between elements within computing
device 642, such as during start-up, is stored in ROM 650.
[0063] Computing device 642 can further comprise a hard disk drive
656 for reading from and writing to a hard disk (not shown), a
magnetic disk drive 658 for reading from and writing to a removable
magnetic disk 660, and an optical disk drive 662 for reading from
or writing to a removable optical disk 664 such as a CD ROM or
other optical media. The hard disk drive 656, magnetic disk drive
658, and optical disk drive 662 are connected to the bus 648 by an
SCSI interface 666 or some other appropriate interface. The drives
and their associated computer-readable media provide nonvolatile
storage of computer-readable instructions, data structures, program
modules and other data for computer 642. Although the exemplary
environment described herein employs a hard disk, a removable
magnetic disk 660 and a removable optical disk 664, it should be
appreciated by those skilled in the art that other types of
computer-readable media which can store data that is accessible by
a computer, such as magnetic cassettes, flash memory cards, digital
video disks, random access memories (RAMs), read only memories
(ROMs), and the like, may also be used in the exemplary operating
environment.
[0064] A number of program modules may be stored on the hard disk
656, magnetic disk 660, optical disk 664, ROM 650, or RAM 652,
including an operating system 670, one or more application programs
672 (such as a user agent or browser), other program modules 674,
and program data 676. A user may enter commands and information
into computer 642 through input devices such as a keyboard 678 and
a pointing device 680. Other input devices (not shown) may comprise
a microphone, joystick, game pad, satellite dish, scanner, or the
like. These and other input devices are connected to the processing
unit 644 through an interface 682 that is coupled to the bus 648. A
monitor 684 or other type of display device is also connected to
the bus 648 via an interface, such as a video adapter 686. In
addition to the monitor, personal computers typically comprise
other peripheral output devices (not shown) such as speakers and
printers.
[0065] Computer 642 commonly operates in a networked environment
using logical connections to one or more remote computers, such as
a remote computer 688. The remote computer 688 may be another
personal computer, a server, a router, a network PC, a peer device
or other common network node, and typically comprises many or all
of the elements described above relative to computer 642. The
logical connections depicted in FIG. 6 comprise a local area
network (LAN) 690 and a wide area network (WAN) 692. Such
networking environments are commonplace in offices, enterprise-wide
computer networks, intranets, and the Internet.
[0066] When used in a LAN networking environment, computer 642 is
connected to the local network through a network interface or
adapter 694. When used in a WAN networking environment, computer
642 typically comprises a modem 696 or other means for establishing
communications over the wide area network 692, such as the
Internet. The modem 696, which may be internal or external, is
connected to the bus 648 via a serial port interface 668. In a
networked environment, program modules depicted relative to the
personal computer 642, or portions thereof, may be stored in the
remote memory storage device. It will be appreciated that the
network connections shown are exemplary and other means of
establishing a communications link between the computers may be
used.
[0067] Generally, the data processors of computer 642 are
programmed by means of instructions stored at different times in
the various computer-readable storage media of the computer.
Programs and operating systems are typically distributed, for
example, on floppy disks or CD-ROMs. From there, they are installed
or loaded into the secondary memory of a computer. At execution,
they are loaded at least partially into the computer's primary
electronic memory. The system described herein comprises these and
other various types of computer-readable storage media when such
media contain instructions or programs for implementing the blocks
described, in conjunction with a microprocessor or other data
processor. The system described can also comprise the computer
itself when programmed according to the methods and techniques
described herein.
[0068] For purposes of illustration, programs and other executable
program components such as the operating system are illustrated
herein as discrete blocks, although it is recognized that such
programs and components reside at various times in different
storage components of the computer, and are executed by the data
processor(s) of the computer.
CONCLUSION
[0069] The various embodiments described above can support a richly
dynamic form environment that permits editing on the client side
and can alleviate many of the server-imposed processing
complexities that have existed in the past. In at least some
embodiments, complex editing scenarios permit users to make complex
editing changes on a form, and have those editing changes captured
and rendered on the client side for later communication to the
server. Particular aspects of at least some of the embodiments
described above can permit scalability, and can, in at least some
instances, be employed in the context of a wide variety of browsers
having different levels of capability, e.g. "thin" and "thick"
browsers.
[0070] Although the invention has been described in language
specific to structural features and/or methodological acts, it is
to be understood that the invention defined in the appended claims
is not necessarily limited to the specific features or acts
described. Rather, the specific features and acts are disclosed as
exemplary forms of implementing the claimed invention.
* * * * *