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.
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)
Ross
