forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [RT] future of v2
Date Fri, 18 Nov 2005 11:54:50 GMT
El vie, 18-11-2005 a las 08:48 +0000, Ross Gardler escribió: 
> 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.
> 

+1

(after you have seen the code we will talk again, ok?)

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

Yes, actually we have since the beginning properties in the
structurer.fv. IMO we should use this mechanism to pass non-location
variables (like theme-name). ...

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

The locationmap is IMO only capable of returning locations and not
non-locations strings. I mean some properties are not based on a
location, but for the rest I strongly agree.

IMO we want to implement a locationmap source protocol. This way it
would be possible to use it like:
Source s = sourceResolver.resolveURI(location);
and everywhere (sitemap,...) like lm://my.property. That makes the usage
within java a lot nicer because I do not have to first contact the input
module.

> >>>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?
> 
> Good reasoning for not having src. Given this reasoning what is wrong 
> with the more "usual" @href?
> 

Yeah, href sounds good but still one can confuse that the actual
contract is coming from the href. Maybe we should use something more
explicit like @dataURI or @dataSrc or dataHref. That reflects what the
attribute actually is doing (personally I think @dataURI would be the
best option).

WDYT?

> >>>>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="/" >
> >         <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.

Yeah, you are right. I will use your proposal because it really "feels" more natural.

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

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


Mime
View raw message