forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [Summary] Recent proposals around v2
Date Thu, 24 Nov 2005 12:45:22 GMT
El jue, 24-11-2005 a las 12:26 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El jue, 24-11-2005 a las 11:48 +0000, Ross Gardler escribió:
> > ...
> > 
> >>Perhaps the contract production stuff should actually be a generator:
> >>
> >><map:match pattern="testContract.**">
> >>   <map:generate type="contract">
> >>     <map:parameter name="dataURI" value="..."/>
> >>     <map:parameter name="contractURI" value="..."/>
> >>   </map:generate>
> >>   <map:serialize />
> >></map:match>
> >>
> >>Another random idea for consideration, not a recomendation, I'm 
> >>wondering why you chose not to do it this way ;-)
> > 
> > 
> > Because not all contracts have dataURI. Besides what about the contract
> > properties from the structurer, how would you pass them to the
> > generator?
> If no dataURI is supplied just detect the NULL and handle it inside the 
> generator.
> This seems more natural to me, because, as you point out, in your 
> current solution when there is no dataURI you are transforming something 
> from nothing - which is not how a pipeline works. Your solution works, 
> but it feels like a hack because the pipeline is not describing what is 
> actually happening.

to get this straight the sample I posted is *NOT* used!!! That was more
an explanation. All pipelines need a generator if you use a transfomer.
That was the only point given this sample. 

The contract is requested in the transformer via java. It is not
transforming something from nothing (that is the point I am trying to
make) because that is not possible. It is only that in xsl a match="/"
*NEEDS* a incoming xml. So if no dataURI is defined then we pass a foo
element to the transformation to start the transformation of the
contract xsl.

> Using a generator means that, regardless of your contract there is 
> always a genuine generator in place, therefore the pipeline describes 
> what is actually happenign.

see above the pipeline is not used at all.

> I can't answer your second question as I haven't seen your existing code 
> so don't know the full processing path. Having said that I don't see 
> what the differnce is since the generator will retrieve the contract.xsl 
> in order to process the file.

Yeah, but I was talking about <forrest:properties/> which are coming
from the structurer and used in the xsl.

> Consider, for example, the problems with Cocoons SQLTransformer - this 
> used an XML file to define an SQL query, this XML file is anlogous to a 
> contract definition and the database connection is anologous to the dataURI.
> I've seen Cocooners say the SQLTransformer was a bad idea, I confess to 
> not knwoing why this is so, but I wonder if this is one of the reasons?
> (remember, I'm not saying your approach is wrong just encouring us to 
> think about the design)

I see I really need to check in what I have otherwise we will end up
being confused.  ;-)

Afterward we can pick this topic up again if needed. 


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

View raw message