xhtml2 and the dispatcher

[Thorsten Scherler <th...@apache.org>]

Hi all,

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

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
find:
<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.

src/documentation/resources/themes/common
|-- 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:property>
    </forrest:contract>
    <forrest:contract name="branding-theme-profiler">
      <forrest:property name="branding-theme-profiler-theme">
        pelt</forrest:property>
      <forrest:property name="branding-theme-profiler">
        <color name="header" value="#ff00ff"/>
      </forrest:property>
    </forrest:contract>
  </forrest:view>

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:

src/documentation/resources/themes/common
|-- 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"
dataURI="lm://project.build-info"/>
or
<forrest:contract name="nav-main-testing" 
dataURI="cocoon://index.navigation.xml"/>

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:transform>
<map:serialize type="xml" />
</map:match>

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. 

salu2
-- 
thorsten

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

Re: xhtml2 and the dispatcher

[Ross Gardler <rg...@apache.org>]

Thorsten Scherler wrote:
> Hi all,
> 
> I had a look at the current xhtml2 plugin and that raised some
> questions:
> 
> 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
> find:
> <map:transform src="{lm:transform.xslt.xhtml2.html}"/>
> Meaning the xhtml2 plugins really awaits xhtml2 output.

Work was halted due to concerns about the approach, it's a "Marie 
Celeste" - That probably means nothing to most none English readers - 
the Marie Celeste was a ship that was found at sea in seemingy perfect 
condition, complete with meals laid out on tables, but with no crew.

Just do what you need to do.

Ross

Re: xhtml2 and the dispatcher

[Ross Gardler <rg...@apache.org>]

David Crossley wrote:
> Thorsten Scherler wrote:
> 
>>I had a look at the current xhtml2 plugin and that raised some
>>questions:
>>
>>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
>>find:
>><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. ... [ snip ]
> 
> 
> Don't worry too much about what the existing "xhtml2"
> plugin does. Remember that it started life during one
> ForrestFriday as a way to start working on xhtml2
> in the core. It was done as a quick plugin to get us
> started without disrupting the trunk or other plugins.
> Ross copied over a swag of sitemap matches from the
> old "views" plugins. So i wouldn't be suprised if it
> is confusing and contradictory.

+1

> Didn't someone already say that the only things of
> interest were a couple of stylesheets and the xhtml2
> sample doc.

Now that the contracts I converted over to XHTML2 are useless (i.e. from 
old views) this is true.

Ross

Re: xhtml2 and the dispatcher

[David Crossley <cr...@apache.org>]

Thorsten Scherler wrote:
> 
> I had a look at the current xhtml2 plugin and that raised some
> questions:
> 
> 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
> find:
> <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. ... [ snip ]

Don't worry too much about what the existing "xhtml2"
plugin does. Remember that it started life during one
ForrestFriday as a way to start working on xhtml2
in the core. It was done as a quick plugin to get us
started without disrupting the trunk or other plugins.
Ross copied over a swag of sitemap matches from the
old "views" plugins. So i wouldn't be suprised if it
is confusing and contradictory.

Didn't someone already say that the only things of
interest were a couple of stylesheets and the xhtml2
sample doc.

-David