The pipeline is the controlling mechanism for a sequence of processes that results in the automatic creation of a UI and supporting components for a Ruby on Rails web application. It can also be used to target other channels too - such as J2EE, ASP.NET, SWF and iPhone.
There is a sequence of processes so that the generation is broken into independent steps, where each aspect of a UI can be grafted on separately. This makes white-labelling and natural language changes trivial.
Ruby on Rails follows an MVC architecture and it is our principal target. We use the Generator to target different parts of the MVC pattern. Almost always, the pipeline generates elements of the View. Occasionally, it generates helper components used in the Controller. Indeed the 'model' itself, originating from XML Schema, is also an output of the pipeline sequence.
When we target Ruby on Rails we generate Rails views and PDF documentation templates from XMLSchemas. When we target other channels or platforms, we generate their relevant resource files.
IAB encapsulates the principle of initial UI generation as a sequence of XSLT processes. Each stage of the sequence enriches the UI with a single orthogonal piece of UI capability. When devising this pipeline sequence we used the metaphor the nuclear waste treatment pipeline, where the fuel is transformed by each plant in the sequence.
In practice, at the start of the process, we accept an input schema , and send it through a number of preliminary steps.
The Pipeline first prepares all of the resources that the base schema provides as separate entities, so we can manipulate and configure them for ordered re-introduction in subsequent steps. The schema gives us a number of assets that we can use later on.
It gives us element names as strings - we externalise these for translation of the application into different human languages. It gives us validation constraints. We externalise these so we can manage them and configure callouts to external validation services. This is the stage where we take out a basic page management configuration so that we can control the sequence of the screens that we will present in the final UI. We can also filter the input schema here.
If there are a number of practical entry points for us into the schema, then we can choose one in this stage. This allows us to render a subset of what the schema defines. Here also we can derive the standard components, or widgets, that are to be found in a a particular product set. There may be common elements, such as a block of contact details or details of a vehicle, and here we tell the pipeline that we want to over-ride and control the default display of these elements. this can be done by brand, or it can be done for a particular company to provide a uniform rendering across all of their UI's.
As the Pipeline concludes, a definition in MXML is created. This contains, in markup, an representation of all the preferences and modifications that have been made during the pipeline steps. In this way, MXML is an intermediate target. With many potential output channels, from the target MXML we can publish to Ruby on Rails, J2EE, Flash, HTML, PDA, Smartphone, Javaphone or iPhone.
The pipeline takes channel, human language, and brand as its parameters. The channel determines the format of the resultant UI definition (e.g. Flash, HTML, PDA etc). The human language determines the language of any text elements of the UI.
In fact there are three pipelines (A, B and X). The first pipeline (A) prepares information from the schema and derives a set of configuration files. The configuration files are enhanced by human manipulation for generating the required balance of brand, language, widget definition, sequencing, conditionality and page flow.
The second pipeline (B) applies all of the orthogonal configuration options to produce the resultant UI. The channel, langauge or brand is simply changed by replacing the appropriate configuration file(s) and reapplying the 2nd pipeline. the factoring-out of orthogonal pieces of information makes replacement, or white-labelling, simpler.
The third pipeline (X) is the means by which the resulting MXML definition is transformed into the required target(s), e.g. rhtml. Pipeline X maybe run many times where different delivery devices are targeted.
The the following diagram shows these pipelines in action. It shows the separate steps in the process, with intuitively the idea that each time something is 'lifted' from the initial definition, it can be modified by a user operation that will influence the final result.
This series of pages explains how each of the steps in the pipeline work. This short movie may also help.
- Pipeline A - Normalize schema and generate configuration models
- Pipeline 1 - XSD Mining
- Pipeline 1.a - Parsing the Schema Library
- Pipeline 2 - Normalise Schema
- Pipeline 3 - Filter Schema
- Pipeline 4 - Derive Language Configuration definition
- Pipeline 5 - Derive Layout Configuration definition
- Pipeline 6 - Derive Complex Type to Widget Preferences definition
- Pipeline 7 - Derive Matrix to configure Conditionality
- Pipeline 8 - Derive Validation Structure
- Pipeline 9 - Derive Data Model
- Pipeline 10 - Configure Default Values by XPath
- Pipeline 11 - Global Configuration