Use of many <xsl:includes..> to modularize a page..is
Hi there, I am trying to modularize "components" into a library of template xsl pages. Many pages don't need a login menu, for example, so I don't want to put that template into say..one big library and include that large library on every page "just in case". So, I thought of doing something like: <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="html" indent="yes"/> <xsl:include href="../include/include.xsl"/> <xsl:include href="../include/login.xsl"/> <xsl:include href="../include/menu.xsl"/> <xsl:template match="root-node"> <xsl:call-template name="frame"> <xsl:with-param name="content"> <div align="center"> <xsl:apply-templates /> </div> </xsl:with-param> </xsl:call-template> </xsl:template> </xsl:stylesheet> Now, the template I call "frame" is in the include.xsl page and it looks like so: <xsl:template name="frame"> <xsl:param name="content" /> <html> <head> </head> <body> <xsl:copy-of select="$content" /> </body> </html> </xsl:template> One reason I like this is it keeps the XSL pages modularized and simple. Secondly, while I will probably not use templates everywhere, it appears to me that I can use templates in such a way as to make it "easier" to read in a module format than just doing straight HTML with inlined XSL use..which is harder to figure out where the XSL templates are, what's being called, etc. As I replied in an earlier post, my main concern is of performance, with second runner up the manageability of the pages. It appears the above is easy to read and very manageable, but now I am wondering if it is slower with all the includes or not. I am also employing a caching routine that reads in all the XSL pages at application startup into Templates objects that are stored in a Hashmap. Then, each request has a mapped XSL name it uses to grab an XSL page at runtime (thereby allowing dynamic choice of XSL pages as well). So by having them all cached and pre-compiled, as well as accessible via a HashMap instead of Hashtable, I am hoping to have circumvented all possible bottlenecks with using XSL that I could have. But just in case..I wanted to get the PRO opinion if the above is a bad design, or if it makes good sense and can ultimately not only solve the possible managability issues with xsl pages, but also keep the performance at its best (or close to it). The last question I have is if there is a way to include files conditionally? Basically, the login menu should only be displayed if a given node exists in the xml input tree. Therefore, if the xml doesn't have the tag, I wish not to include the xsl page (which should increase performance). However, where this might poise a problem is in the pre-loaded cached pages. Infact, a question just hit me..if I pre-load xsl pages which include others, if conditional includes are allowed then how does it resolve this? My guess is that you can not conditionally include xsl pages. Thanks. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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