The overall design of the Xero Display Area needs to be reconsidered. The back-end services have been shown to be effective and fast, but the XSLT used to generate the front end services hasn't been as successful as desirable. First, many browsers don't seem to support XSLT in the same way, and when they do, the XSLT is fairly complex and requires regenerating the entire page. Second, a page generated with XSLT doesn't seem to have quite the same capabilities as one generated with JavaScript or a straight page load does, especially in Firefox.
The internal model and controller for the back end is reasonably effective, and probably only needs some minor tweaks to work well, but the actual view needs to be re-thought. Options for the view include a pure server side generation of HTML pages, a pure JavaScript generation, with JS objects representing everything, or some model that uses chunks of XML templates in some way and combines them. The pure server side generation of HTML has a very significant load issue - it is quite expensive to generate complete pages for the user for a complex application. The server could be designed to refresh just specific areas, but that requires holding a fairly complete representation of the client page on the server side. That makes failover difficult. The pure JavaScript option can definitely be made to work, but it requires a very large amount of JavaScript that maintains some fairly complex behaviour. Because of the complexity of some of the display pages using a mixture of SVG/VML etc, this option isn't deemed to be desirable. As well, the pages will sometimes need server side rendering for embedded devices or other applications where the client cannot perform the desired processing. The existing model is somewhat like a template model, but it isn't sufficiently well developed to work really well, and it depends quite heavily on XSLT.
The new design will use a much more explicitly defined template model, and will include both a JavaScript and an Java or XSLT interpreter for the template. The desire for the XSLT interpreter is to make it relatively pure XSL pages, without any reliance on custom per-application XSL, if possible. Then, based on the browser support, different designs can be used. JavaScript enabled full browsers will use the JavaScript template engine, while mobile devices can use either. JavaScript disabled browsers will use client side XSLT if available, or server side XSLT otherwise. To support JavaScript enabled and disabled versions, some of the TEMPLATES will have to change, but the XSLT applied is intended to be constant. It is also intended that the XSLT be the same for different browsers, with only the templates themselves changing.
As far as the templates are concerned, there are 2 distinct types - templates themselves, which may have some parameters, for example screen size or absence/presence of JavaScript, rows/columns of layout etc, and template-variables. The template-variables are intended to supply information to the templates specific to what the user is doing. The template-variables are considered the "MODEL" component of this design within the MVC overall design. They are thus separated into internal model items that are related to what the user is currently doing/changes to the GUI, and the external model, that is related to external data such as study/series/image meta-data.
There are thus a number of issues to consider about how to manage the templates and what form they should take, and how to use the templates to perform various operations. The templates are clearly XML data, as they are transformed by XSLT. The model data, however, could be represented either by XML or by JSON type variables depending on which is preferable, or some combination thereof.
Template Questions
This section examines how to do different types of things using the template, and how the templates might be implemented in both JavaScript and XSLT.