Using traditional xslt approaches with the Google Search Appliance
One of the challenges to working with the Google Search Appliance (GSA) to develop custom interfaces is the ever growing 10k lines of XSLT code. The traditional approach to work with XSLT is through libraries of functions and files. In some cases, you develop an XSLT that represents the structure of the page and then submodules for the various parts of the page.
A Typical XSLT Layout
Which would be achieved via something like:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"> <xsl:include href="header.xsl"/> <xsl:include href="body.xsl"/> <xsl:include href="footer.xsl"/> <!DOCTYPE html> <html lang="en"> <head> </head> <body> <!-- creates a wrapped header element --> <xsl:call-template name="header" /> <!-- creates a wrapped main section --> <xsl:call-template name="body" /> <!-- creates a wrapped footer section --> <xsl:call-template name="footer" /> </body> </html> </xsl:stylesheet>
The need to store configuration
In addition to needing the ability making the xslt that you are working with more structured and pluggable, there is an immense need to pull your configuration from your standard deployment. Having an xslt which stores all of your environment specific variables allows you to migrate a single stylesheet from your development environment to your production environment.
Are we stuck with the Google Search Appliance
The answer is no. Our good friend pointed out to us the fact that the XSLT files stored with Google Search Appliance frontends are stored in the same directory. Therefor your can reference another xslt file from a different front end via:
<xsl:include "your_frontend_name_without_file_extension" />
With referencing of Google Search Appliance stylesheets, you can achieve a modular xslt structure in addition to providing solid configuration management. It's probably worth nothing that modifications like this may not be directly supported by Google.