El mié, 16-11-2005 a las 16:24 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El jue, 10-11-2005 a las 16:36 +0100, Thorsten Scherler escribió:
> >
> >>Hi all,
> >>
> >>I am working on some java classes that should become the dispatcher
> >>core. While doing it I thought about the usage of contracts. We are now
> >>doing a parallel processing which has influence on the performance.
> >>
> >>Introducing jx:import reduced a wee bit the build time and the recent
> >>update of the lm a lot more. Still it is too slow. Doing some process
> >>consulting on v2 we pointed out that the xsl magic is slowing as well
> >>things down. The idea has to be to slim down the processing.
> >>
> >>IMO contracts have to work standalone. Meaning that the dispatcher will
> >>call the contract with the given properties and include the *result* and
> >>not raw-data and xsl.
> >
> >
...
I now have a first working DispatcherTransformer.java. It is basically
transforming contracts to the resulting transformation markup. We still
need to decide one thing, see below.
> [WARNING - these are off the top of my head thoughts with very little
> consideration - beware of deep potholes]
...
> >>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.
>
I totally agree and have implemented like this. Still there are one
thing we have not considered.
> How about:
>
> <content xpath="/html/body">
> <!-- the HTML generated by the contract -->
> </content>
>
> or an IMS Manifest output:
>
> <content xpath="/IMSManifest/Items">
> <!-- the Docbook generated by the contract -->
> </content>
>
> or FO output:
>
> <content xpath="/stylesheet">
> <!-- the XSLT-FO output -->
> </conntent>
>
> etc.
>
> The xpath could be sepcified in the contract as above,
That ignores that some format may have to insert content into a specific
location rather then in the structure defined in the structurer (*.fv).
Let me explain, guess we have following contract:
<xsl:stylesheet version="1.1"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:param name="nav-main-testing" select="/"/>
<xsl:param name="nav-main-testing-test1" select="'test'"/>
<xsl:template match="/" >
<content xpath="html/body">
<div id="tabs"> <xsl:comment>+ |start Tabs new
+</xsl:comment>
test1: <xsl:value-of select="$nav-main-testing-test1"/>
<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>
and following *.fv:
<forrest:view type="html">
<forrest:css >
/* Extra css */
/* menu */
#leftbar {
width: 25%;
float: left;
background: #CCCCFF;
border: thin solid #000000;
}
/* The actual content */
#content {
margin-left: 25%;
padding: 0 20px 0 20px;
background: #B9D3EE;
}
</forrest:css>
<forrest:hook name="test">
<forrest:contract name="nav-main-testing"
nugget="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:contract>
</forrest:hook>
</forrest:view>
The DispatcherTransformer will output:
<forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0";
xmlns:jx="http://apache.org/cocoon/templates/jx/1.0";>
<forrest:css>
/* Extra css */
/* menu */
#leftbar {
width: 25%;
float: left;
background: #CCCCFF;
border: thin solid #000000;
}
/* The actual content */
#content {
margin-left: 25%;
padding: 0 20px 0 20px;
background: #B9D3EE;
}
</forrest:css>
<forrest:hook name="test">
<content xpath="html/body">
<div id="tabs"><!--+ |start Tabs new +-->test1: x <ul
id="nav-main"><li
class="current"><a class="base-selected"
href="index.html">Home</a></li><li><a class="base-not-selected"
href="samples/index.html">Samples/Tests</a></li></ul><!--+ |end
Tabs +-->
</div>
</content>
</forrest:hook>
</forrest:views>
You see here that the actual location of the content is now:
/forrest:views/forrest:hook/content
telling that @xpath should be xpath="html/body".
Now that would not the right location since it should be insert into
xpath="html/body{$path-in-structurer}". Here "/forrest:hook/content"
Assuming forrest:hook will be transformed to div id="test" the location
would be
xpath="html/body/[EMAIL PROTECTED]'test']"
I call this <content xpath="html/body"/> xpath structure aware, because
it is more a xpath prefix then a fixed location.
Now think you would add
<content xpath="html/head">
<something/>
</content>
That should not be aware of the structure. It should be insert in the
fixed location "html/head" otherwise you would get invalid markup.
To solve this problem I would like to propose to add an attribute
fixedLocation="true|false". So this makes
<content xpath="html/head" fixedLocation="true">
<something/>
</content>
I propose to make the default fixedLocation="false". That means the
content will be injected in the overall structure defined by the
structurer (*.fv), the content is structure aware.
If we solve this issue I can check in a first version of the
transformer.
> or could be
> overidden in the view definition:
>
> <forrest:contract name="nav-main-testing"
> nugget="cocoon://#{$cocoon/parameters/getRequest}.navigation.xml"
> xpath="/html/body/section[position() = 2]"/>
>
> (not sure why we would do that, but you never know)
>
Hmm, ATM I do not see that either because the xpath is defined by the
structurer, isn't it?
WDYT?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
