IDE Issue 5

From MemberWiki

Contents 1 IDE Issue 5: Finding the markup for the HTML template 1.1 Original write-up 1.2 Background 1.3 Jon's proposed recommendation (before 20080103 teleconference)

IDE Issue 5: Finding the markup for the HTML template

Original write-up

During recent IDE WG discussion, the question came up about how our widget markup should identify the snippet of HTML that should be placed inside the (typically) DIV element that will hold an instance of the given widget.

Background

Jon's original proposed widget XML file format attempted to bridge between jMaki's approach and Adobe's approach:

• jMaki supplements each Ajax library with some standard wrapper files, widget.json, component.html, component.js, and component.css, where component.html holds the template. Therefore, in jMaki there is no need to specify the HTML template because the template is discovered based on a file naming convention.
• Adobe includes the template inline with a CDATA section of their <widget> file.
• Jon's proposal attempted to XML-ize the jMaki files by providing a <wrapperFile type="html|css|javascript"> element that would point to the template and its key resource files, where the default file names matched jMaki (i.e., component.html, component.js, and component.css).

While jMaki accomplishes its interoperability magic by leveraging wrapper files, it is unclear that a wrapper file approach is necessary to achieve interoperability and flexible enough to address all scenarios. Two leading Ajax widget libraries, Ext.js and Dojo/dijit, embed their templates inside of their JavaScript class definition. For Ext.js, at the time of the first rendering operation, the widget class passes a string of HTML content to the template utility class (Ext.Template); in fact, it looks like Ext.js does not offer a declarative option for their widgets and developers can only import widgets into the document via JavaScript. (Is this correct?) Dojo/digit has a standard property, 'templateString', that holds the HTML template. Conceivably, in both cases, the template could be built programmatically based on runtime parameters.

Looking at the Gadgets world, Google Gadgets usually includes the HTML for the gadget inline within the metadata file surrounded by CDATA. Apple Dashboard's has a MainHTML property that points to the appropriate externally stored HTML file that makes up the widget.

Jon's proposed recommendation (before 20080103 teleconference)

JON: We discussed this issue at the 20080103 teleconference and there was some leaning towards having separate tags for the markup and the logic, possibly with a supplemental attribute that indicates where the markup and/or logic should be placed within the host document. Below is the proposal BEFORE that teleconference.

In the world today, some systems have the template specified within the metadata file (as CDATA); some systems put the template in an external HTML file; and some systems construct the template in JavaScript. We need to support all of these workflows.

I don't think we should attempt to force Ajax widgets to live in the declarative world. JavaScript-centric widget systems should not have to redesign the way that they work.

Therefore, my proposal is that we have an optional <content> element that can either point to an external file (like jMaki and Apple Dashboard) or include the template inline within CDATA (like Google Gadgets and Adobe's proposal). If a <content> element is not provided (which probably means that the widget is defined fully via JavaScript), then some IDEs may choose to insert an empty <div id="something"> element into the document, along with additional JavaScript on the document load handler that invokes the appropriate widget constructor.

Also, see IDE Issue 6.