A transformation stylesheet defines how to transform a source document into an output document. For instance, an eXtensible Stylesheet Language (XSL) listing includes a set of rules that determine how to transform a source extensible Markup Language (XML) document into an output document. The output document may also be an XML document, or may be another type of document, such as a Hypertext Markup Language (HTML) document, or a Portable Document Format (PDF) document. Typically, an XSL stylesheet defines the formatting style of the output document, such as text color, line spacing, etc. However, the XSL stylesheet may also define alterations that transform the structure of the source document into a different structure. For example, a structure of nodes in a source XML document may be transformed according to the XSL stylesheet to produce an output XML document with nodes arranged in a different order, or replaced with different nodes altogether. Similarly, the structure of a source XML document may be transformed according to the XSL stylesheet to produce an output HTML document that is structurally different and not simply just a translation of the XML into HTML. Thus, a source document can not only be transformed into an output document according to formatting rules that are included in an XSL stylesheet, but more broadly, the XSL stylesheet can be used to transform the source document in many other aspects, beyond just formatting. Transformation rules provided in an XSL stylesheet are particularly useful, because an XSL stylesheet can be employed to transform various source documents containing different information into a single desired uniform output structure and format. An XSL stylesheet is also especially useful for transforming a large amount of source data into a structure and format desired for display in a Web browser program.
Creating Web page “views” of database data is difficult and often very computer intensive. For example, if trying to create a view of a 1000 record database table, the user experience when employing a conventional Web page creation and editing program can be very slow and tedious. Users can create custom Web page “views” of their data, for example, from an XML file, a database table, or a SharePoint™ list. The experience when creating a Data View can be completely “what-you-see-is-what-you-get” (WYSIWYG), i.e., the end-user can be shown exactly how the Web page and the inserted data will look at runtime when viewed in a window of a browser program. From an architectural standpoint, a Data View is built upon Extensible Stylesheet Language Transformations (XSLT), which is a standard for converting XML data to HTML. The Web page creation and editing program can provide automatic generation of XSLT based on formatting that the user does in a design mode. Specifically, when the user makes changes to the data in the design mode, the Web page creation and editing program updates the XSLT to represent the new look and the user can see the data in the Data View as if viewing the data in the Web page within a browser window.
However, because a WYSIWYG tool does dynamic XSLT generation, including the use of actual data, it can cause certain performance and user experience challenges. For example, every change made to the data by a user will typically cause a new XSLT generation to occur so that the change can promulgate back into the HTML that is used to create the Data View, making simple operations such as typing appear sluggish and very unresponsive. XSLT generation for complicated views and large data sets can be very computationally expensive, causing the Web page creation and editing program to appear to be hung. Lastly, sometimes a “WYSIWYG” view is not what the user wants—for example, when a data set is sparse (with rows of data having no values for some of the fields), or very large, the user will likely find that using real data during the editing and design process is actually a hindrance. To address these issues, there are three features that should be developed to help improve the user experience when editing and viewing Web pages that include data.
Specifically, it would be desirable to not update the HTML document using the XSLT transformation for each letter or other input made by the user, since the delay for carrying out the update makes the system seem too slow to respond or sluggish. Still, it would be desirable to show the change made by the user in a cell or field of the data being edited—but not immediately promulgate the change to all corresponding cells of the data. Further, it would be desirable to enable a user to cancel a transformation or update of the data that is taking longer than the user is willing to wait, and the data state that is displayed after the cancellation should be the same as before the user initiated a change to all of the data. Finally, it would be desirable to provide modified preview form views of the data that are not strictly WYSIWYG. In some cases, the user may not need to view all of the data or may want to control how templates are affecting the display of the data.