The Xero view architecture is based on transforming internal and external model data into HTML via XSLT, and potentially styling that with CSS. This transformation breaks up different view parts into either individual XSL templates, lists of XSL templates where the list comes from meta-data and XSL includes that provide additional XSL templates. The use of includes allows separation of different functionality into different components. Additionally, the view separation like this allows a single template to be re-used later on for updating a portion of the display, based on what that template originally requested. This can be instantiated from either XLink or AJAX. A limited amount of the functionality is directly implemented in Javascript.
XSLT Files
The view definition files are all XSLT transforms - these are standard Facelets files that use tags, includes and so on. Like the model files, they can define meta-data in the XSLT file itself. However, unlike the model files, the content of the file is supposed to be fixed given a fixed URL - that is, the XSL that is used doesn't change based on user settings and so on. The XSL that is used may change between browsers and types of devices, but otherwise is not supposed to differ. It should be cacheable in a non-private cache based only on the URL.
The includes for XSLT can be XSLT imports, XSLT includes or Facelets includes. Mostly, Facelets includes should be used for non-shared functionality, while XSLT imports are used for shared functionality. This minimizes the total download size, and allows re-use of the cached portions of the pages where appropriate. A file can decide which type of include it wants by defining the meta-data to refer either to the xhtml file or the xsl file as appropriate.
Overall Page Layout
The overall page layout is directly written in an XSL style sheet template that matches the root documents tag in the source XML and generates the remaining elements of the page. This is usually relatively statically defined - in order to have a new page layout or to add completely new components, the entire overall page is replaced, or perhaps the existing page is modified to include optional or conditional components in new locations.
For example, the tabsFrameXsl.xhtml file at the top defines the XSL to use for the tabsFrame page, like this:
<x:xsl
xmlns:x="http:
xmlns:xsl="http:
xmlns:m="http:
m:xsl="tabsFrameXsl.xsl"
m:tabsVars.inherit="tabsVars"
pageConfig="#\{PageConfig.tabsFrame}"
>
There are some important things to notice in this:
- The x namespace defines some common tags that are used, including the x:xsl tag that automatically includes dependencies.
- The xsl namespace is the standard XSL transform namespace.
- The xmlns:m namespace defines how to declare meta-data.
- The m:xsl and m:tabsVars.inherit both define some meta data. Note the difference, however - the m:xsl line causes this file to plug into a specific other location in the meta-data, whereas the m:tabsVars.inherit plugs another file into THIS meta-data location. The reason that these are both used is that the m:xsl is a specific, single instance that is being extended, whereas the m:tabsVars is a general use of another file
- pageConfig defines an event variable that has the value theme.tabsFrame. This may very well be mapped to metadata.tabsFrame, but it could also just as easily be mapped to some other metadata, perhaps metadata for an AJAX configuration.
Then, in the body, the template to generate the HTML is just a regular xsl template, eg:
<xsl:template match="/"><html>
<head><title>Xero - Frames HTML</title></head>
etc
Page Variables
The page variables define what XSL variables to read from the model data provided. It would be possible to read them directly every time required, but it is often easier to define them up-front. Not all variables will be used for all page types, so the definition of them should be driven by meta-data as a combination of imports, and direct source inclusion of the variable declarations. The declaration in:
m:tabsVars.inherit="tabsVars"
as shown above causes a particular set of variables to be included, in this case as an inline include. The source of that include is:
<ui:component xmlns:ui="http:
xmlns:xsl="http:
xmlns:m="http:
m:includeFacelet="/tabs/tabsVars.xhtml"
>
<xsl:variable name="cid" select="/documents/@conversationId" />
</ui:component>
This particular example probably needs to be moved to a common location, as just about everyone needs this include.
Toolbars
Toolbars are currently handled as some sort of collection (often a <div> tag grouping) of individual items, as defined in the meta-data. Currently there isn't any common code to define a toolbar XSL, but that is likely something that will be added later. An example toolbar is:
<xsl:template name="imageToolbar">
<div style="position: absolute; top:0; left:0; height: 50px;">
<span>
<c:forEach var="tool" items="#{x:sorted(pageConfig,'toolbar')}">
<xsl:call-template name="#{tool.toolbar}" />
</c:forEach>
</span>
</div>
that defines a template that gets called using call-template to imageToolbar. This in turn calls templates defined within the XSL body, or in other files elsewhere.
Command Buttons
A toolbar contains one or more toolbar buttons, some of which maybe menus or other more complex selections. Each button is defined by an XSL template. TODO - figure out how to interact with controller and URL generation systems to refresh page or partial page.
Output Text
There is an XSLT file types/typeOutput.xhtml that provides XSLT templates for rendering the standard elements from the search queries and cycle list. The general format of these is:
<xsl:call-template name="outputElement">
<xsl:with-param name="row" select="row-to-display-from-xml-external-data" />
<xsl:with-param name="type" select="type-of-element-to-display" />
<xsl:with-param name="value" select="value-to-display" />
</xsl:call-template>
To extend or customize the type, change the type being send, and implement a template accessible to typeOutput.xhtml that takes value as a param, and displays the data. Register that in the metadata under converters.YOUR_TYPE.template=TEMPLATE_NAME
To include your XSL or Facelets file, also define: converters.YOUR_TYPE.includeFacelets=YOUR_FACELETS_FILE
Internationalization
There are two approaches that are being considered for internationalization. First, the XSLT files could directly embed internationalized data within them, perhaps as part of the request URL. Caches are already supposed to support this, not replying with a response to a different language for a get request, so that should work just fine. The alternative is to lookup messages and information at XSLT transform time, passing the entire message file to the client. This implies slower start and more data being passed, so it is likely that the XSLT will directly embed the language transforms for labels etc.
Tables
The tables package contains a tableXsl.xhtml facelet file that defines how to handle and render tables composed of data from a specified source (there are also some specific sources provided for the default search results). This uses typeOutput to render the output, so you can customize the output with checkboxes etc custom rendered by creating a new output type as defined in Output Text above. There are at least two examples of this already for selecting a patient and for selecting an individual study.
The tables package is also driven by an XML configuration file. This is provided as $displayedColumns currently. The data to display comes from $docNode. Both of these should be modified to retrieve data from with-param settings instead.
Input Criteria
Similar to outputs, the input for a search can be defined by the typesInput. This is driven by the same values as for the output of text. It typically uses a table to render the actual cells to display.
History
TODO - the history list and current web page should be updateable without have to always refresh the entire page - only with Javascript enabled or with XLink enabled (maybe this will work with XLink - not sure about that yet.)
