forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [Summary] Recent proposals around v2
Date Thu, 24 Nov 2005 12:26:23 GMT
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 />
>>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 

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.

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.

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.

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)


View raw message