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]

Re: nested templates?


> I can't understand where you would 'need' to have nested code.
> 
> The use of selects and template calls would work in all cases I can think
> of, with prehaps the use of for-each but even that is rarely required.
> 
> Prehaps you should give an examle of a transformation which would 'need to
> have nested code'.

Ah, got it.

It is a question of efficiency, correctness, and simplicity.

With the method that you presented before, one _can_ build a page - however
I am of the opinion that it isn't an efficient way of building pages, as I
build very complex pages with large nested trees of code. Of course, xslt
makes that code even larger, so I really am not happy about splitting my
complex pages into many, many, many, many little bits.

i.e.

<html>
<head>
<title><xsl key></title>
</head>
<body>

<xsl apply-template>


</body>
</html>

then

<table>
<xsl apply-template>
</table>

then

<tr><td><xslkey></td></tr>

etc.

is grossly inefficient, and ignores the inherent structure of html (and
indeed all markup) documents.

instead, I need to be able to take a prototype:


<html>
<head>
<title>Foobar!</title>
</head>
<body>

<table>
<tr><td>example</td></tr>
<tr><td>example</td></tr>
<tr><td>example</td></tr>
</table>

</body>
</html>

and _rapidly_ construct a stylesheet from that prototype, which means I need
to retain its correct, original structure.

<html>
<head>
<title><xslkey></title>
</head>
<body>

<table>
<xsl foreach>
<tr><td><xslkey></td></tr>
</xsl foreach>
</table>

</body>
</html>


Now, as you can see, I'm using foreach so no one calls me on correctness -
and this does work.

But I prefer the idea of defining named subtemplates within a scope, so I
can replace them at will with "included" templates. Of course that's only
useful if you're constructing complex documents, but that's exactly what I'm
doing.

For example, I'm building an example xml file which is a complete,
abstracted form definition. Here's a simplified example:

<form>
    <element>
        <label>Form Element</label>
        <name>form_element</name>
        <error>This is some error text</error>
        <input>
            <type>text</type>
            <size>20</size>
            <maxlength>20</maxlength>
            <value>value</value>
            <required>true</required>
        </input>
    </element>
</form>

So, the idea is to build a default 'form layout' which takes care of table
structure, conditionally printing errors, etc - and a set of little includes
which take care of the actual html form element construction:

<xsl:template name="text">
<input>
<xsl:attribute name="type"><xsl:value-of
select="input/type"/></xsl:attribute>
<xsl:attribute name="size"><xsl:value-of
select="input/size"/></xsl:attribute>
<xsl:attribute name="maxlength"><xsl:value-of
select="input/maxlength"/></xsl:attribute>
<xsl:attribute name="value"><xsl:value-of
select="input/value"/></xsl:attribute>
</input>
</xsl:template>


Again, a simple example... but the idea here is to be able to define more
complex form types, like "dependent_pulldown" which allow me to specify a
master set of values, which use javascript to change the second pulldown's
set of values on a change event.

It isn't realistic to store all of those templates inside every form file,
and it's dumb (for reasons you probably beat me to) - so instead of doing
that, I will include them dynamically (if I can get <xsl:call-template
name="$variable_name"> to work correctly) based on the <input> definition
above.

For a number of reasons, that would (er, will be) extremely powerful,
because it will allow me to generate thousands of forms from xml definitions
without any unique presentation code. Which those of you that have built
fairly large scale web apps will know, is a huge deal.

I've done abstraction libraries in php, etc, but xslt seems to elegant way
to do it. This also allows me to standardize my xml manufacturing classes,
so they can also accept xml posts from other places, and do the same
validation and error management as the "html" version does.


ok, the horse is now completely, totally dead.

Anyway, that will all be part of binarycloud r2: http://www.binarycloud.com



_alex


 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]