[OpenAjaxIDE] IDE Issue 5: Finding the markup for the HTML template
jferrai at us.ibm.com
Wed Dec 5 14:57:07 PST 2007
IDE Issue 5: Finding the markup for the HTML template
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.
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
Jon's proposal attempted to XML-ize the jMaki files by providing a
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
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
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
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
support all of these workflows.
I don't think we should attempt to force Ajax widgets to live in the
redesign the way that they work.
Therefore, my proposal is that we have an optional <template> 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 <template> element is provided, then some IDEs may choose
to insert the template into the document. (There are some details about
this insertion process that we still need to discuss.) If a <template>
element is not provided, then some IDEs may choose to insert an empty <div
on the document load handler that invokes the appropriate widget
BTW - I think it is better to avoid the four letters "HTML" within any of
our tag names (e.g., <defaultHTML> because the template might be expressed
in a different language, such as SVG or who knows what.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IDE