RE: [xsl] [design question]

["Martinez, Brian" <brian.martinez@xxxxxxxx>]

> From: "Braumüller, Hans" [mailto:H.Braumueller@xxxxxxxxxxxx]
> Sent: Thursday, February 06, 2003 1:50 AM
> Subject: Re: [xsl] [design question]
> 
> Hi Brian,
> 
> your posting regarding your combination of xslt with 
> javascript is interesting.
> 
> <snip>
> 	<script language="javascript" src="/trs/trip/home/js_home.xsl"/>
> </snip>
> 
> What you are doing there, instead of using a pure javascript ?

We use this method to address a couple of situations:

-- To initialize JavaScript objects for use in client-side applications.  An
example would be allowing users to choose seats when booking flights
(although we don't currently offer this in production).  To build a
graphical seat map using JavaScript and seat availability data from the XML,
I use XSLT to populate a set of arrays representing the seat map on the
client (not actual code, just an example):

<xsl:for-each select="seatmap/rows/row">
  seatMap.addRow(<xsl:value-of select="@number"/>,'<xsl:value-of
select="@is-exit"/>','<xsl:value-of select="@class"/>');
  ...
</xsl:for-each>

-- To repurpose JavaScript code when site-specific configurations are
needed.  We may have different scripting needs for, say, Cheap Tickets as
opposed to Trip.com.  Instead of building a massive, unwieldy library that
tries to be all things to all sites, we output script elements based on the
site profile settings.

> I have choose another way to satisfy the requirement for the 
> interaction with the user-input by the client/browser:
> 
> xsl example:
>    <script type="text/javascript">
>     <xsl:apply-templates select="interaction/selectdocument"/>
>      <xsl:call-template name="webmoneta">
>        <xsl:with-param name="case" select="'javascript'"/>
>      </xsl:call-template>
>    </script>

That's similar to what we do, the difference being that your output code is
inline, whereas we reference an external stylesheet that produces the
javascript as plain text.

> Furthermore we have begun, to test our client-side 
> transformations also by server-side, first to ensure standard 
> coding and secondly in case, we should need it, for new 
> clients, that dont wan´t use IE6 in our business application.

All of our transformations are done server-side, with HTML output.  Of
course, we have a fair amount of logic in the stylesheets to compensate for
obsolete browsers (we can't use <iframe> on Netscape 4.x, etc.), but that's
the price of playing the B-to-C commerce game.

> So my interest is to know, how you implement your following statement:
> <snip>
>   To my embarassment, I had no idea we could invoke our servlet and do
>   transformations via a src attribute in the <script> tag. 
> </snip>
> 
> It could be great, if you could forward a coding example.

It's heavily dependent on how you handle page requests in your servlet.  We
have a rules engine that invokes actions based on either page or user events
(i.e., a request for a specific file can trigger a page event; a command
embedded in a posted form can trigger a user event).  In either case, we
invoke XML formatters specific to a given rule, then apply a stylesheet to
the input and return the HTML output to the client.  (That's really
oversimplifying it, but I'm not a software engineer, so I can't get much
more detailed without sounding like an idiot <g>.)

In the case of a <script> element, we're simply replacing a reference to a
static .js file with a servlet request for a stylesheet containing mixed
JavaScript/XSLT (in our URL structure, 'trs' invokes the main TripServlet):

<script language="javascript"
src="/trs/{$site}/components/common_js_library.xsl"/>

Note the {$site} AVT; it's replaced by the site code from the session
('trip', 'cheaptickets', etc.)  The common_js_library.xsl might look
something like this (I've added in comments):

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
  <xsl:output method="text" media-type="text/plain"/>
  <xsl:template match="/">
    
    <!-- This creates a JavaScript date object to initialize our calendar
tools -->
    var today = new Date(<xsl:value-of
select="/document/session/date/year"/>, <xsl:value-of
select="/document/session/date/month"/>, <xsl:value-of
select="/document/session/date/day"/>);
    
    <!-- site code from profile -->
    var theSite = "<xsl:value-of select="document/site-profile/@site"/>";
    
    <!-- string for writing out URLs in js -->
    var absolutePath = "http://<xsl:value-of
select="document/session/host"/>/trs/<xsl:value-of
select="document/site-profile/@site"/>";

    <!-- etc. -->
  </xsl:template>
</xsl:stylesheet>

The first example, using XSLT to create a client-side date object, came out
of complaints that our search pages would submit the wrong dates.  The
problem was actually that the client's system clock was incorrect, and we
would use it to initialize the calendar (i.e., "var today = new Date();").
Now it's seeded from a date in the input XML, which is far more accurate.

So what you get is plain-text JavaScript source that can be cached locally
by the browser just like any .js file.  It's not as fast as simply loading a
plain text file from the server, but it gives us a great deal more
flexibility.

Ack--this was quite long-winded.  I hope you find it useful.

cheers,
b.

| brian martinez                              brian.martinez@xxxxxxxx |
| senior gui programmer                                  303.708.7248 |
| trip network, inc.                                 fax 303.790.9350 |
| 6436 s. racine cir.                             englewood, co 80111 |
| http://www.cheaptickets.com/                   http://www.trip.com/ |

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list