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. salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
