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 Fri, 18 Nov 2005 08:48:53 GMT
Thorsten Scherler wrote:
> El mié, 16-11-2005 a las 16:24 +0000, Ross Gardler escribió:
>>Thorsten Scherler wrote:


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

Perhaps one for a future enhancement then.

>>>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:
>>> <raw>{nugget}</raw>
>>> <properties>{f:p}</properties>
>>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. 

What is the "properties container"? I ask because my attention is 
starting to turn to the new properties definition system (going to do it 
until after locationmap is complete and 0.8 is out the door).

It seems this is going to need to be considered.

My current thinking is that the vast majority of properties can now be 
removed by having variables in the locationmap. I'm not sure that this 
will fit with your "properties container" concept above.

>>>I have shorten the definition of nugget-contracts in the structurer:
>>><forrest:contract name="nav-main-testing"
>>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?

Good reasoning for not having src. Given this reasoning what is wrong 
with the more "usual" @href?

>>>>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 -->
> To recall what I proposed:
> <xsl:template match="/" >
>         <html>
>           <head/>
>           <body>
>             <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>
>           </body>
>         </html>
>       </xsl:template>
> Should be:
> <xsl:template match="/" >
>   <content xpath="/html/body">
>     <!-- the HTML generated by the contract -->
>   </content>
> </xsl:template>
> 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). 

I'm not sure what you conclusion is here, so I'll add a litttle more 
justification for my proposal:

My proposal "feels" more natural to me. That is, it doens't seem right 
to be putting tags into something that will be removed. I think it will 
cause confusion as to which tags we do need to include and which we 
don't need to include.

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

Awaiting your thoughts.


View raw message