forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: genericMarkup contract
Date Sun, 27 Nov 2005 17:48:08 GMT
El sáb, 26-11-2005 a las 05:13 +0000, Ross Gardler escribió:
> Diwaker Gupta wrote:
> > Hi devs, Thorsten
> > 
> > I'm using the genericMarkup contract, and was wondering if it could be 
> > simplified. In particular (and I copy this from index.fv in seed-v2), lets 
> > say I want to insert a <hr/> somewhere in my template. For that, I need this

> > XML snippet:
> > 
> > 	  <forrest:contract name="genericMarkup">
> >             <forrest:properties contract="genericMarkup">
> >               <forrest:property name="genericMarkup">
> >                 <hr/>
> >               </forrest:property>
> >             </forrest:properties>
> >           </forrest:contract>
>  From what I understand, it is soon to be:
>   	  <forrest:contract name="genericMarkup">
>                 <forrest:property name="genericMarkup">
>                   <hr/>
>                 </forrest:property>
>            </forrest:contract>
> > I find that way too verbose, and confusing. Why is <hr/> sitting in a 
> > property?
> If it weren't in a property it would have to be in XSL, which would be 
> more verbose wouldn't it?

Yeah forrest:property will be "translated" into xsl:param. I mean out of
*each* forrest:property we do something like:
Transformer transformer = contract.getContractTransformer();

El vie, 25-11-2005 a las 22:04 -0800, Diwaker Gupta escribió:
> I'm not sure I follow. How is a <hr/> in a forrest:property any
> different from 
> directly under a forrest:contract? Perhaps I'm missing something
> really 
> obvious here, but why can't we simply copy over everything between
> the 
> contract tags (for the genericMarkup contract) verbatim (as CDATA,
> for 
> instance) over into the output?

Because you can have x *different* property in a contract. The
surrounding forrest:property has the identifier @name to treat the
properties differently in the contract. If you just dump everything into
the contract container you would have only *one* property and like ross
pointed out you would have to extract the different ones then in xsl
which have to be (much) more verbose then that.

> > And while I was looking at it, I had another question: since 
> > <forrest:properties> is a child element of a <forrest:contract>, why
do we 
> > need that contract attribute? 
> It's gone in the planned POJO version I think (see above). Thorsten will 
> correct me if my understanding is incorrect.

You mean the @name from forrest:contract? If so we need to identify the
contract we are currently processing. If you mean forrest:properties
then Ross just correctly pointed out that this will be gone in the next


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

View raw message