Michael,
The code I gave was merely an exercise for me to see if and how this
could achieved. The actual application will have to support loads and
loads of dynamic (multi-lingual) texts/code in the final output,
combinations of which can be as diverse as possible as well. So in
Martin's code I have several xsl:param's across the XSLT for each
variable, this will only increase as the amount of variable texts
increases. That's what I meant. My main concern is to separate the
final layout as much as possible from the XSLT, so as to allow other
people to design/play with it (within the limitations set by me
ofcourse), and to be able to re-use as much XSLT-generating code as
possible for generating output for different agents (XHTML, content
for mobile phones, plain text, etc).
Thank you for your answers (everybody sofar), it's a (fun!) challenge
to not think of XSLT in a procedural way.
Edwin
On Fri, Jul 4, 2008 at 7:08 PM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
I can't quite see why lots of xsl:params should be needed, but I haven't
really studied the detail of the problem (in fact, I don't think you've
really shown us the full detail). But I would think that a generated XSLT
stylesheet should in principle be faster than interpreted code.
I've used this technique with clients to generate stylesheets for capturing
data from (thousands of similar) Excel spreadsheets, and performance never
became an issue.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--