Another strategy is to arrange your system to do all the calculations/retrieval once and put the data into a secondary document, retrieved via the document() function -- which, if you plug in an appropriate entity resolver, can be done without having to spend time generating and re-parsing XML syntax.
Another is to have an extension which does all that and returns a Java object which contains the results, then pass that to additional extensions to retrieve the data. That way the retrievals are relatively inexpensive and stateless, so reordering or repeating them is pretty much harmless. Another is to have your environment do the precalculations and pass the values in as stylesheet parameters. Then the stylesheet just has to declare those parameters and refer to the values by name, much as if they were stylesheet variables. ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html) From: Michael Ludwig <mil...@gmx.de> To: xalan-j-users@xml.apache.org Date: 06/30/2010 02:27 PM Subject: Re: xsl/xalan problem Adrian Herscu schrieb am 30.06.2010 um 20:03 (+0300): > > Then how would you advise to implement such a system? > I really need to get some input during the transformation. Depends on what kind of input you have in mind and what's practical to do. One strategy is to append your runtime data (user input, database output, whatnot) to your main XML document which you construct in memory, and then have XSL code handle it as you see fit. /root /data ... /data ... /my:runtime-input -- All your extra input goes here. /my:object-A ... /my:object-B ... /my:more-context -- Michael Ludwig
