Xero Web Page Design

The design of web-pages within Xero use a pattern that is designed to allow re-use by various types of web browsers, including mobile devices, non-Javascript enabled browsers and full AJAX capable browsers, where the primary data is retrieved using restful patterns, and a minimal amount of non-restful data is retrieved in order to improve continuity in the non-AJAX environments.

Three different primary types of pages are provided for Xero. These are data pages, view pages, and XSLT transforms. The view pages are the ones that the user actually navigates to, and are intended to be quite small, only linking the data and the XSLT transforms. The data pages are the results of search queries, images to display, user preferences and other related items. The XSLT are the transforms used to modify the data and create a visible display.

Data Pages

Data pages provide the raw data to display. Examples of a data page include an XML representation of a search query, an XML representation of a study organization/meta-data, or a JPEG image. The intent of this type of page is that they should be fully restful, and sufficiently well documented to allow use by different applications to provide different types of client applications. Where possible, standard pages, such as WADO pages should be used. It is quite important that these pages have at least a short time to live in the browser cache, as the data pages are often used by several frames, and should not be reloaded

There is a common design pattern used for this type of page, and that is the filter pattern. The desired output is created by starting with one or more sources, which are combined and transformed by various filters to produce the final output. This is supported by some meta-data classes to make writing filters easier, as well as determining whether to apply a specific filter.

Meta Data Filter Servlet

There is a filter servlet based on the meta-data services that can be useful for creating data pages. That is the meta-data filter servlet. This service is a standard Java Servlet that takes as it's source a meta-data configured set of filters, and has a configurable maximum age for the lifetime. If the meta-data is configured to read JNDI based services as filters, then it is possible to extend this servlet filter by deploying new JNDI based filters, without having to modify the original servlet filter code.

View Pages

For XSLT capable browsers (that is all except mobile browsers), the view pages are a reference to an XSLT transform, possibly determined by the page parameters, along with a list of references to data pages, and finally some number of view-specific settings. For example:

<documents>
<search>search.xml?ModalitiesInStudy=MG</search>
<userPrefs>userprefs.xml?user=Fred</userPrefs>
<searchCriteria ModalitiesInStudy="MG" />
<resultsPerPage>15</resultsPerPage>
</documents>

where the search line contains the URL of an XML document for the results of the search, the userPrefs contains a reference to data page containing the user preferences for Fred, and the search criteria and results per page are view-specific settings, most likely modified earlier by the user, or else these might be default values.

As view pages contain more data, especially optional data, it is recommend that a meta-data generated list be used to determine their contents so that items can be added into this view document that is used by specific XSLT transforms.

XSLT Transforms

The XSLT transform takes the view page, and reads the various referenced documents, turning them into viewable pages. Like the data pages, it is expected that the XSLT transforms will be restful pages, mostly fixed for all users for a given installation/initial page view. Different transforms will be used for different themes, as well as for different pages. As well, meta-data lists should be used where appropriate to define portions of the XSLT transforms so that the page can be extended with additional commands, layout and so on.

It is not expected that the XSLT will define colours, fonts, sizes and things like that. Those areas should be left to be defined by standard CSS pages, as that provides a better separation of configuration between layout and style, and allows sites to modify some amount of the page without needing to understand XSLT.

The XSLT transforms are likely to be used in 3 closely related fashions: mobile browsers (no client side XSLT/Frame support), Javascript disabled browsers and full AJAX browsers. In order to permit re-use for different purposes, it is important to understand how to design the various parts of the XSLT.

Mobile Browsers

Mobile browsers typically have very limited processing capabilities, low bandwidth and cannot store large amounts of cached XSLT and data pages. They also have very limited screen real-estate, and don't usually support any type of frames. Thus, the normal design is that each page is a single self-contained page, usually with a small number of links to enable navigating to and from the next and previous page that is normally viewed. For Xero, that means starting at the search page, and likely omitting the list page, using links directly to view the series page, and from there going to the report, switching studies, and display series. On the image page, the only option is the next/previous pages, and going back to the series page.

The implementation of the mobile views should still use the same XSLT layout and commands where possible, so that changes and improvements to one area still propagate to the mobile device, and in specific, customizations at a site should propagate to all three browser types. This is a hard design constraint to fulfill, as the mobile device itself cannot handle the XSLT. That requires a custom set of web-pages that re-use the XSLT with some specific meta-data settings that disable frame based navigation and instead use direct navigation. As well, there needs to be a servlet that does some amount of caching of the data, view and XSLT pages, and renders the pages using an XSLT transform on the server.

The design for this isn't finalized yet, but is likely to consist of the following pieces:

• Web-page cache for data pages (and XSLT if the transform engine doesn't cache those pages)
• XSLT Transform engine (this may cache the XSLT directly)
• Customized Facelets tags to enable writing XSLT that can be used for frameless, framed or AJAX browsers, and will generate page updates appropriately based on the type of page it is generating.

This area is still being designed/worked on.

Non-AJAX Browsers

A non-AJAX browser is typically one where Javascript has been disabled for security reasons, but where XSLT is supported, as is Frame support. In this environment, all updates need to be page updates, and any conversational state needs to be kept on the server side, or embedded within a URL. The conversational state is intended to be embedded within the view page. Updates to the view page can occur from any frame when a user clicks on a link reference. To keep the view pages restful, and cacheable (for performance reasons), the view page should also handle being posted to for updates. This causes the client side cache to be discarded, according the the HTTP standard.

AJAX Browsers

An AJAX browser allows the conversational state to be stored client-side, with very little or no state stored on the server. This type of environment allows quite a lot more flexibility than either of the other options, and it is expected that many operations will only work in this environment.

There are currently 3 primary areas where javascript is expected to be used. Updates of an area of a screen occur when a user changes some setting such as the sort order of a list, or the display layout of a page. Dynamic command handling occurs when the user starts some operation that requires continuous updates on the screen, such as displaying a menu of commands, or tracking the window level of an image as the user moves the cursor. Finally, updating the conversational state occurs when the user has completed some command. The first operation is expected to be handled by updating the XSLT that applies to some portion of the screen. Again, custom tags in the display layout should be provided to enable an update of a portion of the screen rather than the entire page being displayed. This will use a portion of the XSLT for the entire page, but it will re-use that portion from the non-AJAX browser version (with customizations where appropriate to handle AJAX calls instead of web-calls.)

The dynamic updates are expected to be customized for AJAX and written for the specific behaviour required. If related behaviour is required for non-AJAX browsers, then support for that would need to be written independently of the AJAX support. Finally, for the updates of conversational state, some of the behaviour maybe embeddable in tags and automatically customized for AJAX/non-AJAX use, while other behaviour such as modifying the history list in the client would be custom for the AJAX design.

One minor note here, is that if XLink is ever supported by most browsers, then that is an alternative to AJAX for most of the client side conversational support, as it allows multiple pages to be updated at once, which allows the get parameters to store the conversational state rather than needing to store it on the server or client. This would allow the non-AJAX browser to be much close in functionality to the AJAX browser.

Themed Instances

A site may have some number of "themed" instances where customizations are made for specific groups of users. This will likely be just a specification of what the style sheets and icon images etc are used.

CSS Pages

CSS pages will be used to set the colour, fonts and general styling of the pages being viewed. The CSS to use should be settable via the theme.