I have committed the templating system I've been working on. This is useful, but we have a fair bit of work to do on it yet.
Here's a simple example of how I recently used it: Use Case ======= I needed to provide four separate widgets for browsing data from a remote web service. The service provided a REST API which returned data in XML format. Each of the four browse interfaces needed a search box and it was required that all of them had an identical user interface. It was also critical that each user interface was useful on different device form factors and to users with different accessbiity needs. The Template ========== I first built a template to display one type of results (workflow definitions). This provided the functionality required by the system but only worked with one type of content. Since I had previously built a "base" template which provided the basic widget layout I needed I made this new template "extend" the "base" template. Next I generalised the template so that I could easily provide configuration parameters for each of the things that needed to change for each widget, e.g. URL for search query, code for generating HTML output from results In generalising I realised that having to write javascript to process the results was, perhaps, sub-optimal since interface designers are rarely Javascript programmers. I decided to provide an example of how other methods could be used to convert the XML results in the HTML for inclusion in the template. I opted for XSL processing of the XML, but I could (at least in theory) have used any other templating system or programming language. The Widgets ========= I now had a template which was fully customisable and a widget definition which provided the necessary information to create an instance of this template (displaying workflow definitions). Next up I created the other three widget definitions by defining the properties file that identified the REST API endpoints and the XSL needed to transform the results. The total time for creating the other three widgets was about 30 minutes. Pretty rapid! The Future ======== Because each of these widgets is based on a common template I can respond to requests for changes in the UI or common functionality by simply editing the template and regenerating all the widgets. All three widgets will reflect the changes consistently. For example, at present the results are displayed in an accordion. When a section is expanded it shows summary information for that item. Having worked with the widgets for a while I think it would be useful to have the first result expanded by default - no problem, change it in the template and it's done in all four widgets. Another future requirement is that when a widget is selected in the browser another widget should respond by showing the full detail of that item. By adding this inter-widget communication code to the template we can add this feature to all widgets automatically. A final example of why the template is useful is that I will soon be creating a new widget that pulls resources from another application. It will take just a few minutes to create this browse widget thanks to the existence of this template. The Code ======= The template code is at /widgets/template (if this code is accepted after review then we need to rename widgetTemplates to something since they are not really templates) A readme.txt provides instructions for use (need to move this to the website) The widgets I built in the above use case are at: http://code.google.com/a/apache-extras.org/p/rave-in-context/source/browse/#svn%2Ftrunk%2Fwidgets Ross -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
