- Introduction to Utopia
- A Fresh Beginning
- How This Enhances the DataGrid
- The JavaScript Scope of Things
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
How This Enhances the DataGrid
As you may recall from my previous articles, we had constructed an object model just to prove that JavaScript is capable of supporting one (just wait, a compiler is around the corner). While it made implementation somewhat cleaner, we were still stuck with the submission of data to the grid in the form of nested arrays. Not only that, but the addition of properties came in the form of HTML-style strings—functional, but prone to errors not easily uncovered.
What if we encased these elements in an XML document? Let's look at a sample envelope:
<SOAP:Envelope xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1">
<SOAP:Body>
<HTMLGrid:Properties>
<bgColor scope="row" rownum="3" value="red">
<fontSize scope="all" value="12">
</HTMLGrid:Properties>
<HTMLGrid:Data>
<addRow>
<rowData>
<cellData>One</cellData>
<cellData>Two</cellData>
<cellData>Three</cellData>
</rowData>
</addRow>
</HTMLGrid:Data>
</SOAP:Body>
</SOAP:Envelope>
I don't want to provide yet another review of basic XML operations, but I'll mention a couple of the features of this fragment:
First, as the adoption of XML continues to grow, a problem will begin to creep into the mix—a problem that plagues application teams with a single member who insists on using global variables: using the same name to describe the same basic data for different purposes.
Namespaces are not a new concept, but as data starts getting shared worldwide in the universal language of XML, there is little doubt that getting into the habit of using them will give you a head start.
The last feature I'll mention is the fact that the file is now divided into two categories—properties and data. This is an added benefit to XML. The behaviors, styles, and data can all be included in our Document Type Definition (DTD) or XML schema. With the right specifications, fragments can contain elements that change the behavior of the table, add/update data to the table, or both.
On its face, this seems to solve both our problems. A clean mechanism for both modifying data and establishing properties is available. By elaborating for a moment, I'll point out a couple of directions for this model. First, if the CSS standard should just happen to extend somewhere, or if you choose not to account for every existing style, the DTD must simply allow for an fragment similar to the following:
<HTMLGrid:Properties> <cssStyle scope="row" rownum="3" value="color:red"> </HTMLGrid:Properties>
Second, if you want to disseminate this data in a static fashion, an XSL transformation could be written capable of turning this data into formatted HTML. Why, after going through all this effort, would you want to revert to a static table? Well, there's still the possibility of a browser not supporting JavaScript (heaven forbid). There's also the need for security of your system—only allowing authorized users to modify data. And finally, there's the looming threat of needing to support even the most rudimentary of cellular browsers, and an XSL could be tailored to distribute the data in a platform-dependent manner.