7
edits
Changes
no edit summary
Now this is the first pass at this "factlog". In time, we won't be able to load all the RDF needed in one go and some of the incremental loading mentioned above will be necessary. For now though, the templates work. Our greatest concern was that there is no event to tell when RDF loading is complete (hence the hokey script used in the opening splash screen) and that loading seems to block the browser. Make RDF loading asynchronous and give us an "RDF Loaded" event and we can live with the templates for now. Of course, that's just this site.
=== Comments [[KurtCagle]] ===
I'm somewhat new here, and hope I'm not intruding on protocol, but I wanted to pass a few comments concerning databinding and templatization that we're beginning to develop for the release of Netscape 9. There are a number of facets of the templates design which have caused us to burn entirely too many cycles, especially given that we typically end up rolling our own XBL based components for more complex user interfaces. Specifically,
==== The Challenge with Canonicalization ====
Many of the resources that we are dealing with typically rely upon non-RDF XML through third party web services providers. To be able to utilize this code with existing templates, we have to explicitly perform an XSLT transform into RDF and then have to rebuild lists, grids and trees again with different predicates in order to handle variable data. This canonicalization step has to be performed outside of the scope of the templatized binding, with enough variability in the canonicalizations as to make it difficult to maintain the library of transforms.
==== XPath/XSLT Bindings ====
XBL Widgets that we've rolled from scratch typically utilize a binding architecture based on either XPath alone or explicit XSLT transformations as attributes on existing elements. This works especially well in an AJAX model. For instance,
<pre>
<grid mc:model-src = "http://www.myresources.com/myEmployeeService/" mc:refresh="no" mc:model-type="xpath">
<columns>
<column id="emp_id" label="Employee ID"/>
<column id="emp_name" label="Employee Name"/>
<column id="emp_building" label="Employee Building"/>
</columns>
<rows model-set="//item" >
<row>
<label mc:model-value="@emp-id"/>
<label mc:model-value="emp-name"/>
<label mc:model-value="location[1]/building-number"/>
</row>
</rows>
</grid>
</pre>
or
<pre>
<grid mc:model-src = "http://www.myresources.com/myEmployeeService/"
mc:transform="http://www.myresources.com/xml/templateTransform1.xsl"
mc:refresh="no" mc:model-type="xslt"/>
</pre>
The effect in the first case is to define an implicit data source (model-src) and a model-set which provides an XPath expression that returns a node-set. The columns here work with an iterated context of nodes defined by the model-set to assign values into the rows generated from the rows. The model-value, in turn, provides XPath expressions for retrieving content relative to the current node in the set. The second passes in a transform file that then performs the maps relative to the root node of the data model.
The model-type attribute would make it possible to alter the data source and acts as a flag to help interpret the subordinate namespace attributes. It would likely be an entry point into a more complex data-provider model that would support RDF, xpath, xslt, sql, and perhaps ldap.
==== Decoupled Data Referencing ====
We've also developed a model similar to that proposed by Sean McMurray above in which the data provider can exist independently of (but referenced by) the template:
<pre>
<data model-src="http://www.myresources.com/myEmployeeService" id="employees" refresh="60s" model-type="xpath"/>
<grid mc:model="#employees">
<columns>
<column id="emp_id" label="Employee ID"/>
<column id="emp_name" label="Employee Name"/>
<column id="emp_building" label="Employee Building"/>
</columns>
<rows mc:model-set="//item" >
<row>
<label mc:model-value="@emp-id"/>
<label mc:model-value="emp-name"/>
<label mc:model-value="location[1]/building-number"/>
</row>
</rows>
</grid>
</pre>
I personally like this model as it 1) meshes more closely with the XForms model, which we also utilize, 2) decouples the data provider from the data consumer, and 3) makes it possible to modify the model and have it automatically update the bound component.
==== Timing ====
One final comment - The fact that there are already emerging a number of different approaches to data binding indicates to me that a more extensive standard for data modeling and binding should be developed sooner rather than later, in order to cut down on the number of forked implementations.
''Kurt Cagle, Netscape 9 Architect''
