The primary factor governing the split into modules should be ease of
maintenance. 60 functions in one module seems a little bit large for my
taste (and the larger it gets, the harder it becomes to modularize it), but
it's not unreasonable, especially if the functions are small.
I don't think either of your arguments for making it monolithic are sound.
You could split it into modules, and provide a "front end" module that does
nothing but xsl:include all the others.
Michael Kay
http://www.saxonica.com/
-----Original Message-----
From: frank johnson [mailto:fjhnsn(_at_)gmail(_dot_)com]
Sent: 10 March 2009 21:17
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: [xsl] include multiple utility modules vs one larger one?
Hello,
We have coded a number of XSL functions (about 60) used by a
series of XSL stylesheets (about 15). We've put all the
functions into one large common XSL which is then imported
into all the stylesheets.
This has the effect of including much more into a given XSL
than is generally used, but was done to (1) ease the problem
of knowing which modules to import into which XSLs and (2)
avoid posssible circular references which could result from
nested imports. Functionally, our approach has seemed to work
well so far.
Is this considered a best practice or have we implemented an
anti-best practice? Aside from an increase in compile time,
is there any significant penalty or downside to this approach?
Thanks in advance.
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--