| [orion-dev] widgets, templating, and i18n in a dijit-free world |
We talked a little on the call today about widget templates, including the security risk of concatenating NLS strings into HTML that will be parsed. [1]
I thought it was worth sharing what's going on in the Orion dialog world (which made heavy use of dijit templating and data binding).
The dialog documentation on the wiki [2] has a section on lifecycle and templating that describes the approach.
I'm trying to be very agnostic initially in where templates come from. Some people like to put them in HTML files, but we currently don't have a story for pulling in template fragments with requirejs. So sometimes it's just easier to include the string in the _javascript_. (This is what the banner does, for example). So here's an approach that is working well in the dialogs:
1) Your dialog prototype should define a TEMPLATE variable that contains the HTML. It's up to you to decide how that variable is bound, by reading a file, by processing a template in your main HTML page, or by simply setting the value of that variable in-line in your js.
2) You simply make sure the TEMPLATE is bound before calling the dialog initialize sequence (see the doc).
3) Refer to i18n variables in the template using ${MyMessageKey}. For example:
<span role=button>${Push Me}</span>
4) Set your message catalog in the prototype so the code can find it. (this.messages = message)
5) The dialog prototype will create a document fragment for the template, bind all of the NLS variable to the specified catalog, and insert it into the dialog frame.
Step 5 will be of general use to anyone who needs to bind NLS variables into their templates. So I have pulled it out into a common module. For any document fragment you've retrieved from a template, you can use
littlelib.processTextNodes(myFragment, messages);
For more "widgety" things I'm finding that there aren't too many templates because (at least in my case) the widget itself doesn't really use a template, it tends to attach behavior onto some HTML given to it by a client. But the client code (such as command framework generating menus and tooltips) uses these same kinds of techniques when the template is complex, or otherwise just uses DOM node creation code.
susan
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=392469
[2] http://wiki.eclipse.org/Orion/Dialog_Support#The_Dialog_life-cycle