RE: [xsl] use cases for d-o-e

Subject: RE: [xsl] use cases for d-o-e
From: "Hunsberger, Peter" <Peter.Hunsberger@xxxxxxxxxx>
Date: Wed, 9 Jan 2002 09:47:32 -0600
> Does somebody know of uses which are not completely theoretical and
> don't fit in one of the categories above?

I do, almost, have one example...  The example comes about due to backwards
compatability requirements with older browsers where the only way to format
output data is by placing it in table cells.  With a more modern browser one
can use CSS and positioning to do away with the problem.

In this particular case I have dynamically constructed tables where the
input XML for generating the tables is not completely perfect:

	<search>
  	  <patient>
            <name_first title="First name"/>
            <name_last title="Last name"/>
            <br/>
            <mrn title="Patient Number"/>
            <dateofbirth title="Date of birth"/>
            <sex title="Sex"/>
            <br/>
            <address_addr1 title="Address"/>
            <address_city title="City"/>
            <address_state title="State"/>
            <address_zip title="Zip code"/>
        </patient>
	</search>

the "<br/>" elements have been added by some GUI designer as needed to
indicate when to start another table row for output formatting purposes.
Since the outer "search" elements start the table off and running, by the
time we handle the "br" elements we far enough down a XSLt template
structure that re-working the templates to carry all the other table
formatting up and down the tree to properly nest the table rows (as a result
of hitting a "br") would make the XSLt much larger and harder to maintain.
Instead, the template to handle them currently looks like:

	<xsl:template match="search/*/br">
   		<tr/>
	</xsl:template>

This works fine (due to IE quirks?) but, I suspect, really should be a
d-o-e'd "</tr><tr>", which would produce the output HTML that one normally
expects.

I'm not sure what the use case is, but it's either "handle older browsers
where we can't use CSS (well structured output)" or it's "handle slightly
flaky input XML", or some combination of the two. I suspect this isn't quite
what you're looking for, but it might suggest a real use case that is
similar... 


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


Current Thread