Thanks Dimitre and Michael.
The compiler we're using produces "warnings" about circular references
which we took to mean they were inefficient, bad or otherwise to be
avoided.
Most of the functions are helpers, 20 lines or less. We could
definately group them into broad categories or create a separate XSL
for each function. I like the idea of an XSL agregator to bring in the
others. Since you are recommending it, I assume there's no penalty for
doing that, even if we create an XSL for each function. Correct?
On Wed, Mar 11, 2009 at 6:43 AM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
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/
On Wed, Mar 11, 2009 at 1:37 AM, Dimitre Novatchev
<dnovatchev(_at_)gmail(_dot_)com> wrote:
So, what is bad with circular references from <xsl:import> directives?
Every compliant XSLT processor should deal with this -- it is not an
error.
As for the technique of importing one module which then imports a
number of module, this is something well-known. See for example this:
http://fxsl.cvs.sourceforge.net/viewvc/fxsl/fxsl-xslt2/f/func-standardXpathFunctions.xsl?revision=1.9&view=markup
--
Cheers,
Dimitre Novatchev
--~------------------------------------------------------------------
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>
--~--