Thorsten Scherler wrote:
El mié, 16-11-2005 a las 16:24 +0000, Ross Gardler escribió:
Thorsten Scherler wrote:
...
Have you considered making the contractTransformer a standard Cocoon
transformer rather than an Element?
My reasoning is that this will give us the capability to leverage the
existing Transformer framework and create other types of contract that
are not XSL based.
I have not yet thought about that but it is definitely worth looking at.
Need to have a look at it.
Perhaps one for a future enhancement then.
My current testing code ignores ATM forrest:properties because I thought
about them a wee bit and since contracts are now standalone we could:
a) keep it like it is - passing the properties as xsl:param to the
stylesheet like
transformer.setParameter("someProperty", somePropertyElement);)
I like the way it is, it enables me to override it in many ways.
b) include them into the raw data document like:
<data>
<raw>{nugget}</raw>
<properties>{f:p}</properties>
</data>
What are the advantages to this?
I am not sure myself. ;-) One advantage for b) is that till now we used
default variables (coming from forrest core, such as {$root}) that we
now need to explicitly pass to the xsl because it is standalone. Doing
this via a) forces the contract author to add a <xsl:param/> to the
contract. If we use b) then we can just dump them in the properties
container and the contract author would get the nodes from
e.g. /data/properties/forrest/root.
What is the "properties container"? I ask because my attention is
starting to turn to the new properties definition system (going to do it
until after locationmap is complete and 0.8 is out the door).
It seems this is going to need to be considered.
My current thinking is that the vast majority of properties can now be
removed by having variables in the locationmap. I'm not sure that this
will fit with your "properties container" concept above.
I have shorten the definition of nugget-contracts in the structurer:
<forrest:contract name="nav-main-testing"
nugget="cocoon://#{$cocoon/parameters/getRequest}.navigation.xml"/>
Hurrah!
Why nugget="",
That is out of historical reasons.
why not src=""?
...because that gives the impression that it is the src file of the
contract implementation and not the requested raw data.
I prefer src as it is used in other parts of Forrest/Cocoon.
What about above said?
Good reasoning for not having src. Given this reasoning what is wrong
with the more "usual" @href?
d) transform hooks into format specific markup
e) transform all above to the final page
The question is how can we make contracts more generic. One way is to
get rid of head|body="true|false". I thought that each contract has to
provide this information from the resulting transformation.
Above contract solved the issue.
Does it?
A potential problem with the proposed approach is that it is still quite
specific to the final output format, in this case HTML. This is not a
problem for Forrest, using XHTML2 as an intermediate format, but you
want the contracts to be independent of the format, so I guess something
a little more generic may be better.
How about:
<content xpath="/html/body">
<!-- the HTML generated by the contract -->
</content>
To recall what I proposed:
<xsl:template match="/" >
<html>
<head/>
<body>
<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>
</body>
</html>
</xsl:template>
Should be:
<xsl:template match="/" >
<content xpath="/html/body">
<!-- the HTML generated by the contract -->
</content>
</xsl:template>
IMO that is nearly the same. ;-) You specify with @xpath what I am doing
with the element xpath. Your solution would help having one generic xsl
on the end of the transformation (e), where my recommendation would make
it necessary to have format specific (e).
I'm not sure what you conclusion is here, so I'll add a litttle more
justification for my proposal:
My proposal "feels" more natural to me. That is, it doens't seem right
to be putting tags into something that will be removed. I think it will
cause confusion as to which tags we do need to include and which we
don't need to include.
The other thing that we have to solve is the hooks stuff (d) where we as
well have ATM a format specific solution.
I will consider it.
Awaiting your thoughts.
Ross
