forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scherler....@juntadeandalucia.es>
Subject Properties for contract (was Re: Dispatcher 1.0 - towards a stable version)
Date Wed, 10 Sep 2008 08:32:06 GMT
On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
> Hi all,
> 
> I will have some time in the next week to enhance the performance of the
> dispatcher. The performance always have been the Achilles’ heel of the
> dispatcher. 

One thing that I identify as performance killer is described in [1].

The properties that we pass to the contract are passed as parameter. It
seems this is only possible as org.w3c.dom.Document which is a big
downer.

I sees various workaround to the problem:
1) Not allow custom xml for the contract properties in the structurer
but only Strings (much we have in forrest.properties.xml). Then passing
the string to the xsl.
Same is valid for the whole forrest.properties.xml that we as well pass
to every contract as param. Instead passing the whole file it makes
sense to just pass the key and the value to the xsl transformation.

2) Aggregate the properties to the dataUri outcome and not pass
parameter at all to the transformation. The result would look something
like:
<content>
 <dataUri>
  <!-- result of the dataUri -->
 </dataUri>
 <structurerProperties>
  <!-- properties defined in the strucutrer for this contract -->
 </structurerProperties>
 <properties>
  <!-- forrest.properties.xml -->
 </properties>
</content>

The first solution is fast to implement and seems quite clean. The
downside is that we cannot use xml anymore. Which actually IMO is not
that bad since maybe we start to use the actual forrest.properties.xml
to configure contracts.

The second solution is more complicated to implement since the
aggregation has to be done in the DispatcherTransformer which does not
feel right but we could use xml in the properties.

Personally the cleaner solution is 1 but that would break downward
compatible by a couple of contracts.

WDYT?

salu2

[1] http://marc.info/?l=xalan-j-users&m=122095755104055&w=2 
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Mime
View raw message