[OpenAjaxIDE] IDE Issue 5: Finding the markup for the HTML template

Jon Ferraiolo jferrai at us.ibm.com
Wed Dec 5 14:57:07 PST 2007



URL: http://www.openajax.org/member/wiki/IDE_Issue_5

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


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 <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
id="something"> element into the document, along with additional JavaScript
on the document load handler that invokes the appropriate widget
constructor.


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...
URL: http://openajax.org/pipermail/ide/attachments/20071205/6ff8b22c/attachment.html 


More information about the IDE mailing list