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: > >>> > >>> {nugget} > >>> {f:p} > >>> > >> > >>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 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: > >>> >>>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: > >> > >> > >> > >> > >> > > > > To recall what I proposed: > > > > > > > > > >
> > + |start Tabs new + > > > > > select="$nav-main-testing/navigation/tab/ul[@id='nav-main']"/> > > + |end Tabs + > >
> > > > > >
> > > > Should be: > > > > > > > > > > > > > > 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)