forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject xhtml2 and the dispatcher
Date Tue, 13 Dec 2005 15:59:10 GMT
Hi all,

I had a look at the current xhtml2 plugin and that raised some

a) when I started the only thing I saw where xhtml2 comes into the game
is in the document-to-xhtml2.xsl. Meaning we only have to deal with
xhtml2 documents to transform and not internal stuff like navigation,...

b) this thought is contradicted by the internal.xmap pipe where I can
<map:transform src="{lm:transform.xslt.xhtml2.html}"/>
Meaning the xhtml2 plugins really awaits xhtml2 output.

That is actually not like I thought multiple format structurer will
work. Contracts and the dispatcher are format independent meaning there
is no such last transformation. That is done in the dispatching phase
and with markup specific transformation of hooks. Let me explain this
thought and a wee bit how I thought the dispatcher will work with
different output formats.

The structurer is requesting/defining the output for a certain format
(type="format"). Meaning that what is done in the xhtml2 plugin is
really (type="xhtml2") because the contracts are going to output xhtml2
markup and not html.

|-- css
|   |-- branding-generic-css.ft
|   `-- branding-theme-profiler.ft
|-- html
|   |-- ajax-example.ft
|   |-- branding-css-links.ft
|   |-- branding-tagline.ft
|   |-- branding-theme-switcher.ft
|   |-- nav-main-testing-foo.ft
|   |-- nav-main-testing.ft
|   `-- siteinfo-meta.ft
`-- js
    `-- cssStyleSwitcher.js

Each folder (css, html, js, xml,...) can offer contracts that will
output the format defined by the folder name where the contract resists.

In our small example e.g. the branding-generic-css.ft will output css
definitions that have been defined in the structurer. The important
thing is that it will output text and *not* markup. That is the reason
why we define it for css and not for html:
<forrest:view type="css"  hooksXpath="/">
    <forrest:contract name="branding-generic-css">
      <forrest:property name="branding-generic-css-input">
/* Extra css */
    p.quote {
      margin-left: 2em;
      padding: .5em;
      background-color: #f0f0f0;
      font-family: monospace;
    <forrest:contract name="branding-theme-profiler">
      <forrest:property name="branding-theme-profiler-theme">
      <forrest:property name="branding-theme-profiler">
        <color name="header" value="#ff00ff"/>

This structurer definition will output a css stylesheet (text format)
which is dynamically generated. This is more or less the same we have
done in old fashion skin with the profiler.css.xsl extended as a
contract. You can still define css in the type="html" part of the
structurer with the branding-css-links.ft contract but that will lead to
an inline css generation (links/style elements) rather then an external
file (e.g. above can generate index.css). 

Now the xhtml2 plugin is aiming to offer contracts of the format xhmtl2
(better this is what I understood). With the above said we need to 
mkdir xhtml2 and the tree would like:

|-- css
|-- html
|-- xhtml2
`-- js

Then we still would need to define html contracts that are producing the
final markup (based on xhtml2 input), but that is not a problem since
all contracts can connect to different business services (via @dataURI).
The html contracts will use the xhtml2 output as input and generate html
markup for output.

I call this xhtml2 contracts data models. Please compare the
dataModel.xmap, here we define such input snippets via the sitemap but
this can be done better with contracts (like with the xhtml2 contracts).
We are using the data models in a structurer like:
<forrest:contract name="siteinfo-meta"
<forrest:contract name="nav-main-testing" 

After written this and if you still with me the next steps should be:
a) define which contracts should be available in xhtml2 (like
content-main). Things like branding-tagline.ft I do not think need to
output xhtml2, but that is just me and it will need discussion.

b) replace the current pipes in dataModel.xmap with the xhtml2
contracts. This should be done by defining a structurer for the
requested uri. A test match would look like:
<map:match pattern="test.**.xhtml2">
<map:generate src="lm://resolve.structurer.{1}" />
<map:transform type="dispatcher">
  <map:parameter name="type" value="xhtml2" />
  <map:parameter name="hooksTransformer"
   value="lm://hooks-to-xhtml2.xsl" />
<map:serialize type="xml" />

Note: lm://hooks-to-xhtml2.xsl will still have to be written.

c) change current html contracts to transform the new xhtml2 contracts
where we changed them. The html contracts would now get a new input
format/structure and need to change the transformation accordantly. 


"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message