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/[EMAIL PROTECTED]'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)
