This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Use of many <xsl:includes..> to modularize a page..is it bad?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]