forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [RT] future of v2
Date Wed, 16 Nov 2005 17:50:11 GMT
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 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.

I have not yet thought about that but it is definitely worth looking at.
Need to have a look at it.

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

Like said I am not sure which way it is better. ;-)

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

> >>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="/" >
            <div id="tabs">
              <xsl:comment>+ |start Tabs new +</xsl:comment>

              <xsl:comment>+ |end Tabs +</xsl:comment>

Should be:
<xsl:template match="/" >
  <content xpath="/html/body">
    <!-- the HTML generated by the contract -->

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

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.

> 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, 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)
> You may find the code in Cocoons XPatch tool useful in implementing this.

Thanks Ross for taking the time and write some input that helps a lot.


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

View raw message