forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [Summary] Recent proposals around v2
Date Wed, 23 Nov 2005 17:45:16 GMT
El mié, 23-11-2005 a las 14:34 +0100, Cyriaque Dupoirieux escribió:
> Thorsten Scherler a écrit :
> 
> >Hi all,
> >
> >trying to summarize a wee bit the recent discussion around v2.
> >
> >forrest:contracts & forrest:properties
> >**************************************
> >Structurer
> >^^^^^^^^^^
> >1) nuggets (extra data requested by the contract)
> >Nuggets are now defined in the contract element instead of in the
> >forrest:properties. As well the former @nugget is now called @dataURI to
> >reflect better the function of the attribute.
> >e.g.
> ><forrest:contract name="nav-main-testing" 
> >        dataURI="cocoon://index.navigation.xml"/>
> >
> >  
> >
> Ok, I like "nuggets" to be renamed into "dataURI".
> English is not my native language - as you recently remind to the 
> community ;-)  

jeje, not yet on a public list. ;-)

> - and my dictionnary told me that a nugget was a small 
> piece of gold - indeed. 

:) Sure we living in the golden age. ;-)

> So - at the beginning - I spent a long time 
> wandering what was the use a small piece of gold with my contracts :-P .

to make them more valuable. ;-) jeje

> The naming is still an important problem - good choice of variables, 
> parameters or contracts name, naming rules for properties or contracts 
> and so on... (It's good Ross started to clarify this point)
> 

Yes, I agree we starting to see the light at the end of the tunnel. 

> >2) The properties have lost their parent node. 
> >e.g.
> ><forrest:contract name="nav-main-testing" 
> >  dataURI="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:property name="nav-main-testing-test3"
> >  
> >
> >>xxx</forrest:property>
> >>    
> >>
> ></forrest:contract>
> >
> >  
> >
> Ok, Nice if there is only one property.
> The code may be clearer with this...

I agree, please note that the example code is only my developing code.
Some stuff may only test features (in this case passing more then one
property to the transformation).

> 
> >Contract implementation
> >^^^^^^^^^^^^^^^^^^^^^^^
> >1) contracts are now standalone, which means that they need to
> >match="/".
> >  
> >
> Do we have to add a patern in order to match "/" in every contracts ?
> (I have very simple contracts wich do not match anything - kinds of 
> Macros to insert code...)

Yes, all xsl contracts have to start with:
<xsl:template match="/" >
...
</xsl:template>
even if they do not need to match any nodes!!!

> 
> >a) If raw data (dataURI) is requested it matches the first element of
> >the dataURI. 
> >  
> >
> Same as before,
> 
> >b) If no dataURI is requested the dispatcher passes a dummy document to
> >the transformation containing only one element: forrest:foo.
> >e.g.
> ><xsl:stylesheet version="1.1"
> >xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> >  <xsl:param name="nav-main-testing" select="/"/>
> >  <xsl:template match="/" >
> >    <content>
> >      <div id="tabs">
> >        <xsl:comment>+ |start Tabs new +</xsl:comment>
> >        <xsl:copy-of 
> >          select="$nav-main-testing/navigation/tab/ul[@id='nav-main']"/>
> >        <xsl:comment>+ |end Tabs +</xsl:comment>
> >      </div>
> >    </content>
> >  </xsl:template>
> ></xsl:stylesheet>
> >  
> >
> Same as before again no ?

please read b) again. "If no dataURI is requested the dispatcher passes
a dummy document to the transformation containing only one element:
forrest:foo."

Means that the processing is:
structurer defines contract 
-> contractBean uses the definition and 
either request the dataURI or prepare the dummy foo document (source) 
-> this.contractTransformer.transform(source, result) 
-> the result will be inserted in the overall result again.

> 
> >2) the resulting transformation have to go into a container element
> >named "content".
> >
> >...
> >
> >b) Till now we assumed that all hooks go
> >into /html/body but this need to be more flexible. I propose to add a
> >new attribute @hooksXpath to the forrest:view. I propose this attribute
> >@hooksXpath as required.
> >
> ><forrest:view type="html" hooksXpath="/html/body">
> > <forrest:hook name="htmlBodyHook"/>
> ></forrest:view>
> >
> >that will be transformed into 
> ><html>
> > <body>
> >  <forrest:hook name="htmlBodyHook"/>
> > </body>
> ></html>
> >  
> >
> Ok, so a standard HTML fv file will look like the following - am I right ? :
> 

no sorry. The below example will not work out of multiple reasons.
1) to define hooksXpath="/html/header" (btw should be /html/head) in
html means that all hooks structurer will be added to the head. The
problem is that contracts normally decide if it is necessary to add
something in the head. IMO the SoC concept would not force the designer
to know that some contracts have to be insert in the head. 
2) @type have to be unique in a structurer definition (*.fv). Here the
javadoc comment I added it to the attribute:
    /**
     * <code>forrest:view</code> element is used to structure contracts
and
     * hooks into format specific container. It allows to configure x
different
     * format for the request. The attribute which identify a view
format is
     * <strong>format</strong>.
     * 
     * <pre>
     *                 &lt;forrest:view
&lt;strong&gt;format&lt;/strong&gt;=&quot;html&quot;/&gt;
     * </pre>
     */
    public static final String STRUCTURER_FORMAT_ATTRIBUTE = "type";

> <?xml version="1.0" encoding="UTF-8"?>
> <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0"  
> xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">
>   *<forrest:view type="html" hooksXpath="/html/header">*
>     <forrest:css url="common.css" media="screen" rel="alternate 
> stylesheet" theme="default"/>
>      ...
>     <forrest:contract name="branding-theme-profiler" ... />
>     <forrest:contract name="siteinfo-meta"/>
>     <forrest:contract name="siteinfo-meta-navigation"/>
>   *</forrest:view>*
> 
>   *<forrest:view type="html" hooksXpath="/html/body">*
>     <forrest:hook name="container">
>       <forrest:hook name="header">
>          <forrest:contract name="...">
>           ...
>       </forrest:hook>
>       <forrest:hook name="page">
>        ...
>       </forrest:hook>
>     </forrest:hook>
>   *</forrest:view>*
> </forrest:views>
> 
> I think it's the first time I realise tere is a forrest:view type attribute.

see above. ;-)

> Are we ready to make views such as :
> 
> <forrest:view type="php" hooksXpath="/html/body">
>  <forrest:hook name="htmlBodyHook"/>
> </forrest:view>
> 

That means you will output php. Yes, in theory, yes, but I have not
concentrate on this ability yet.

> or :
> 
> <forrest:view type="pdf" hooksXpath="/document/body">
>  <forrest:hook name="pdfBodyHook"/>
> </forrest:view>
> 

that means you will output pdf. Hmm, ATM no because you would output fo.
Then you would need to use a serializer fo-to-pdf. ...but yes. ;-)

Like I said many times before the x formats is the ultimate aim for the
dispatcher, but ATM it has no priority till we have the transformer.

> 
> >c) We need another attribute in hooks @element which would not create
> >a div but the value of @element:
> ><forrest:hook element="html">
> > <forrest:hook element="body">
> >  <forrest:hook name="htmlBodyHook"/>
> > </forrest:hook>
> ></forrest:hook>
> >
> > that will be transformed into 
> > <html>
> >  <body>
> >   <forrest:hook name="htmlBodyHook"/>
> >  </body>
> > </html>
> >  
> >
> Ok, I have no use case for this...
> 
> Thank you for this interesting summary...
> 

Thank you for your comments and request for clarification that is
helping a lot. :)

salu2

> Salutations,
> Cyriaque,
> 
> 
> >
> >salu2
> >  
> >
-- 
thorsten

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


Mime
View raw message