[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|