forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [Summary] Recent proposals around v2
Date Thu, 24 Nov 2005 10:46:22 GMT
El mié, 23-11-2005 a las 20:50 -0800, Diwaker Gupta escribió:
> This is not in SVN yet right? Just confirming, because I don't see anything 
> yet... :)

No, I had a simple transformer that was "just" transforming the
contracts into the position where it could be found. 

I wanted to check that in but started to clean the code and added
comments. Doing this I then started to apply recent proposals and it is
not that easy. ;-) The challenge is to create a DOM result with SAX
events out of attributes of contracts and the structure path of the
hooks and then inject it again in the SAX result stream. I hope to have
a first version ready after the weekend. 

> On Tuesday 22 November 2005 2:05 pm, Thorsten Scherler wrote:
> > Contract implementation
> > ^^^^^^^^^^^^^^^^^^^^^^^
> > 1) contracts are now standalone, which means that they need to
> > match="/".
> Sorry I don't think I follow the terminology here :( By stand-alone, you are 
> implicitly saying that earlier contracts depended on something else?

Yeah, it was dependent from calls in the themer.html.xsl
(xsl:call-templates name="*-body"). 

Now you can see what I mean with following example:
<map:match pattern="testContract.**">
  <map:generate src="{dataURI}" />
  <map:transform src="{contract.xsl}"/>
  <map:serialize />

That is just an example it is not working like this in the transfomer
but very similar. It means that all contract xsl should be testable as
itself. You generate the dataURI (or a dummy document) and pass it to
the xsl. A transform does not work *without* a generate.

Why? XSL needs to get invoked and since we get away with the
themer.html.xsl and the xsl magic happen in there, we need to have a way
to invoke the transformation. In java you prepare a transfomer and then
transform a source document with a transformer to the final data.

from the
TransformerFactory tFactory = TransformerFactory.newInstance();
 DOMSource stylesource = new DOMSource(node);
 Transformer transformer = tFactory
         OutputKeys.OMIT_XML_DECLARATION, "yes");
 transformer.setOutputProperty(OutputKeys.INDENT, "yes");
 transformer.setOutputProperty(OutputKeys.METHOD, "xml");
 this.contractTransformer = transformer;

The "stylesource" is the xsl from the contract. Then later on we are
going to use this transfomer (the xsl is now set) and transform the
contract (this.contractTransformer.transform(source, result);):

DOMSource source = new DOMSource(this.getContractRawData());
DOMResult result = new DOMResult();
this.contractTransformer.transform(source, result);

We cannot use this.getContractRawData() if it is null! That is the
reason why we added a fallback that if a contract do not need dataURI
then we generate a foo element to have a trigger. Like said our trigger
was before (xsl:call-templates name="*-body") now *all* contracts have
to start with 
xsl:template match="/"

>  I know 
> this has something to do with moving processing over from XSLT to Java, but 
> it'll be great if you can elaborate this a bit :)

Hope that explain it a wee bit better, please keep on asking because
this point really seems to be not clear to everyone.

> > a) If raw data (dataURI) is requested it matches the first element of
> > the dataURI.
> So a dataURI can contain multiple "elements"?

Yes, of course, better said the document returned by the dataURI

>  What are these "elements"? 

That depends on what dataURI you request. e.g. if you request
dataURI="cocoon://index.navigation.xml" then the first element is

> Or 
> did you mean to say that if there are multiple dataURI attributes, the value 
> of the first one will be used?

no, multiple dataURI have not been implemented. 

> > b) If no dataURI is requested the dispatcher passes a dummy document to
> > the transformation containing only one element: forrest:foo.
> What does the Dispatcher do with forrest:foo then? 

Nothing it is only there to trigger the transformation.

> Is this just an artefact of 
> the implementation or something more fundamental? 

Yes, we cannot use this.getContractRawData() if it is null! Which means
the contract could not be transformed.

> In other words, why can't I 
> have the Dispatcher just use a null value if no dataURI is specified? 

Because javax.xml.transform.Transformer.transform()
     * Process the source tree to the output result.
     * @param xmlSource  The input for the source tree.
     * @param outputTarget The output target.
     * @throws TransformerException If an unrecoverable error occurs
     * during the course of the transformation.
    public abstract void transform(Source xmlSource, Result
        throws TransformerException;

will not work if the "xmlSource" is null. That is the reason why we do:
         * if we do not have a nugget add a foo element to the raw data
         * invoke the transformation.
        if (!contract.isNugget()) {

> Just 
> being curious here, I have no problems with the way it is right now :)

:) thanks for asking for clarification.

> > 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
> IIUC, this bodes well for the architecture in general. Earlier we had some 
> discussions on using the terms "head" and "body" in templates since they 
> seemed to be specific to HTML. By using xpath expressions, we have removed 
> this limitation completely!

yes :) 


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

View raw message