Subject: RE: [xsl] include multiple utility modules vs one larger one? From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Wed, 11 Mar 2009 10:43:55 -0000 |
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@xxxxxxxxx] > Sent: 10 March 2009 21:17 > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx > 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.
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] include multiple utility , Michael Kay | Thread | [xsl] XPath 2 (and hence XSLT 2) st, Liam Quin |
RE: [xsl] XPath 2 (and hence XSLT 2, Michael Kay | Date | RE: [xsl] URI of the passed Source-, Michael Kay |
Month |