forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] future of v2
Date Wed, 16 Nov 2005 16:24:31 GMT
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 have a basic doing the above written. It is a bean
> containing besides other:
> private Document contractImpl;
> private Document contractRawData;
> private Element contractTransformer;

[WARNING - these are off the top of my head thoughts with very little 
consideration - beware of deep potholes]

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.

> 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 have shorten the definition of nugget-contracts in the structurer:
> <forrest:contract name="nav-main-testing"
> nugget="cocoon://#{$cocoon/parameters/getRequest}.navigation.xml"/>


Why nugget="", why not src=""?

I prefer src as it is used in other parts of Forrest/Cocoon.

>>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 -->

or an IMS Manifest output:

<content xpath="/IMSManifest/Items">
   <!-- the Docbook generated by the contract -->

or FO output:

<content xpath="/stylesheet">
   <!-- the XSLT-FO output -->


The xpath could be sepcified in the contract as above, or could be 
overidden in the view definition:

<forrest:contract name="nav-main-testing"
xpath="/html/body/section[position() = 2]"/>

(not sure why we would do that, but you never know)

You may find the code in Cocoons XPatch tool useful in implementing this.


View raw message