Dispatcher (Draft - feature under development)

We developed the structurer to let the user decide where to place elements in e.g. html pages. We started this work with the skinconf.xml where you could configure certain elements and their positions. These elements were known under certain names. It was up to the skin designer to support this configuration and the elements.

The work started with grouping elements (the ones from skinconf). We used css-contracts that we added as @attributes e.g. <div id="content-main"/> . That made it possible to use the same elements in different skins. For the full list refer to the initial contract list

Around this contracts we developed a configuration Domain Specific Language - called the structurer. The structurer allows us to define the order in which forrest:contracts appear, and also to group them using forrest:hooks.

forrest:hooks are containers that are only used for layout reasons. They do not add any content nor functionality to the output. They add only layout information to the output. Actually e.g. a <forrest:hook name="layoutId"/> will be transformed to <div id="layoutId"/>

forrest:contracts are functionality or extra content that a theme can use to display the request. Sometimes a contract delivers format-specific markup, other times it delivers a format-independent string. We decide different kind of contracts, static one (like described in the contract howto), semi static (which offer configuration parameter in the structurer) and dynamic contracts (which offer semi-static configuration and/or requesting the content).

The structurer is also a configuration file for the dispatcher. The new thinking on the dispatcher is that one can include any content from any given business service by dispatching a request against it. In "old fashion" skins and in v1 contracts we assumed a given data model. In the dispatcher there is no given data model any more. All data has to be defined in the structurer so that they can be dispatched.

The result of the leather-dev development was grouped functionality in named containers. We gave those code snippets names (based on their functionality) and called them contracts. This naming enabled us to keep the contract separate from the positioning of the code itself. Furthermore, since major parts of the code of skins has never been documented, we started to add for each contract a description and an explanation on how to use this contract. The skinconf.xml gave an excellent source for this documentation effort, since it described most features of the pelt skin.

Contracts are standalone, self explaining, configurable pieces of xsl templates created purely for ease of maintenance.

Since these contracts are working from the input given in the structurer, it works on different input sources. One can pass variables into the contracts that can be used to apply presentation logic in the xsl (like sorting order, ...).

"A naming convention is an attempt to systematize names in a field so they unambiguously convey similar information in a similar manner." wikipedia

That led to the development of the "leather-dev" skin which established a semantic container approach for div elements. Leather-dev evolved from the "pelt" skin and used almost the same functionality (contracts). We had started to encapsulate functional code into templates, but there have been still in 4 xsl files and without any documentation on what they are doing and how to use them. The problems with leather-dev was pointed out in the mail "status on leather-dev?". The main proplem was to limit users to only one html-skeleton which was way too limiting regarding design. Since we had now grouped functionality in named containers we were ready to start the dispatcher (aka forrest:views).