Hi all,
trying to summarize a wee bit the recent discussion around v2.
forrest:contracts & forrest:properties
**************************************
Structurer
^^^^^^^^^^
1) nuggets (extra data requested by the contract)
Nuggets are now defined in the contract element instead of in the
forrest:properties. As well the former @nugget is now called @dataURI to
reflect better the function of the attribute.
e.g.
<forrest:contract name="nav-main-testing"
dataURI="cocoon://index.navigation.xml"/>
2) The properties have lost their parent node.
e.g.
<forrest:contract name="nav-main-testing"
dataURI="cocoon://index.navigation.xml">
<forrest:property name="nav-main-testing-test1" >x</forrest:property>
<forrest:property name="nav-main-testing-test2" >
<foo/>
</forrest:property>
<forrest:property name="nav-main-testing-test3"
>xxx</forrest:property>
</forrest:contract>
Contract implementation
^^^^^^^^^^^^^^^^^^^^^^^
1) contracts are now standalone, which means that they need to
match="/".
a) If raw data (dataURI) is requested it matches the first element of
the dataURI.
b) If no dataURI is requested the dispatcher passes a dummy document to
the transformation containing only one element: forrest:foo.
e.g.
<xsl:stylesheet version="1.1"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:param name="nav-main-testing" select="/"/>
<xsl:template match="/" >
<content>
<div id="tabs">
<xsl:comment>+ |start Tabs new +</xsl:comment>
<xsl:copy-of
select="$nav-main-testing/navigation/tab/[EMAIL
PROTECTED]'nav-main']"/>
<xsl:comment>+ |end Tabs +</xsl:comment>
</div>
</content>
</xsl:template>
</xsl:stylesheet>
2) the resulting transformation have to go into a container element
named "content".
a) We proposed two new attributes for the "content" element (@xpath and
@structureAware).
Actually I gave it a second thought and I think it would be better to
only apply @xpath under the new circumstances of path-prefixing hooks.
The attribute @xpath determines that the elements within the content
container should be insert in a given location. In html for example some
function need to be inserted into the /html/head and/or /html/body.
The location of the /html/body *normally* is defined through a
forrest:hook path (we called it structureAware="true"). So I propose
that
<content>
...
</content>
stands for structureAware="true" -> the contract will be injected in the
path determined by the forrest:hooks.
When the @xpath it set, the container content will be added to the value
of the @xpath.
<content xpath="/html/head">
...
</content>
Like element("/html/head").appendChild(newChild).
b) Till now we assumed that all hooks go
into /html/body but this need to be more flexible. I propose to add a
new attribute @hooksXpath to the forrest:view. I propose this attribute
@hooksXpath as required.
<forrest:view type="html" hooksXpath="/html/body">
<forrest:hook name="htmlBodyHook"/>
</forrest:view>
that will be transformed into
<html>
<body>
<forrest:hook name="htmlBodyHook"/>
</body>
</html>
c) We need another attribute in hooks @element which would not create
a div but the value of @element:
<forrest:hook element="html">
<forrest:hook element="body">
<forrest:hook name="htmlBodyHook"/>
</forrest:hook>
</forrest:hook>
that will be transformed into
<html>
<body>
<forrest:hook name="htmlBodyHook"/>
</body>
</html>
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
