Widget Initialization Using JSON, HTML Custom Tags and XML Files / Page 2 | WebReference

Widget Initialization Using JSON, HTML Custom Tags and XML Files / Page 2


[previous] [next]

Widget Initialization Using JSON, HTML Custom Tags and XML Files [con't]

After the list object is returned, it's shown calling showList function, which uses the innerHTML property of the DIV element to render the widget in the HTML page. Several articles have been written about the use of innerHTML or DOM functions to place elements, so that discussion isn't part of this article. If you know the code you're writing, there's no reason not to use innerHTML, as it's faster in all browsers, especially IE.

The innerHTML method to display html code is much faster in Internet Explorer compared to the use of DOM methods. The problem with innerHTML is that you may write invalid code and the browser will try to best display it. But different browsers will display it in different ways. Therefore, what I meant is that if you know the code you are writing is valid, there is no reason not to use innerHTML method, as it is much faster in all browsers, especially Internet Explorer (See Example 1).

HTML custom tags

In this case widget properties are defined by using inline HTML Custom Tags. In order to create a widget using these properties, these tags have to be parsed after the document has loaded. This alternative has an extra overhead to parse the HTML Custom Tags and also it's not as flexible as the previous one. All property values are limited to string datatype, in contrast to the JSON option that can use any Javascript object. However, writing HTML pages should be easier for an inexperienced programmer or Web designer, as they can write them using any Web editor of their preference. As Web editors become more powerful, these pages can be validated by using a custom DTD to prevent coding errors, as well as having code assistance to speed up page development.

It's possible that in a development project the team in charge of the presentation layer might not have advanced Javascript programming skills. If this is the case, an alternative like this could be quite handy:

As explained above, the first thing to do is to parse all the <list> Custom Tags contained in the page. That is done after the page loads by using the onload event and calling parseHtmlLists function. parseHtmlLists iterates over all the lists and calls readHtmlList to obtain an object representation of every list. After the list object is obtained, it is shown by using showList function:

Example 2: HTML Custom Tags

XML files

The use of HTML Custom Tags has the disadvantage that, to benefit from DTD validation, a custom DTD must be written by moving away from HTML DTD standards. Why do we want to get rid of standards? They appeared to be used in the first place. This can be solved using separate XML files to declare widgets. By doing this, an extra layer of flexibility is added, as widget declaration is separated form the HTML page, allowing its reuse. For example, an address list declaration might be reused along several pages: Customer Detail, Company Detail, etc. This alternative still has the same disadvantages of extra overhead for parsing time and the advantages of DTD validation and code assistance. Figure 1 shows code assistance in XML Spy XML editor:

XML files can be loaded by using on one hand XMLHttpRequest and on the other hand by using Microsoft.XMLDOM ActiveX (IE) or document.implementation.createDocument (non IE browsers). None of them are native cross browser, both options are browser dependant and have some workarounds to make them work. I have seen examples, in which both methods were used either together, combining them or separated. I prefer using XMLHttpRequest as I found it more cross browser (only the creation of the request object is different), but any working method will do the trick. Note: When using any of these methods, the XML file must be loaded in an asynchronous way, since we don't want to wait and start loading a widget after the other one has finished.


[previous] [next]