RE: include multiple utility modules vs one larger one
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: 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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format