Re: [xsl] mode computation case
2010-08-31 12:17:56
Dear Andre,
I see the appeal of your line of thinking, but I also agree with Mike
that there are other facilities and features in XSLT 2.0 that could
meet the need, perhaps as gracefully.
In particular, have you looked at XSLT's capability of assigning more
than one mode to a template, and in particular to the new keywords
for modes #default, #current, and #all? Using these in combination
with cascading template matches (using xsl:next-match and explicit
priority settings when necessary) one might accomplish a great deal
of what you are after.
In the simple case:
<xsl:apply-templates select="$nodetree" mode="#current">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
Please forgive me if your question assumes this kind of thing is
already being done.
Cheers,
Wendell
At 07:08 AM 8/31/2010, you wrote:
Hi Michael,
Interesting idea.
My use-case is about processing a highly structured XML document in
many different ways, including for various types of transformations,
calculations, statistics, reporting, and presentation, as the
document is maintained and evolves, hence the use of different
modes, typically selected, along with a set of parameter values,
from user input, for example. For a more concrete example, the
document could be a model from a building, or a car, or anything one
may wish to model as a structured XML document, ideally, the
universe;). I see this pattern as quite basic and fundamental. I
also feel that it needs to match on the nodes in the different modes
rather than on the modes in different nodes.
What do you think?
Regards,
Andre
I'm sure one can devise ways of using this feature, but the real
question is whether there are already acceptable ways of solving
the user-level problem. To answer that question, we need a
high-level description of the transformation you want to carry out.
One alternative that comes to mind is to do
<xsl:apply-templates select="@mode">
<xsl:with-param name="nodetree" select="$nodetree"/>
...
</
and then have template rules
<xsl:template match="@mode[.=mode1]">
...
</xsl:template>
etc.
On 31/08/2010 5:27 AM, ac wrote:
Hi,
I have something like
...
<xsl: variable name="var1" select="...some value or node-set
generating expression"/>
<xsl: variable name="var1" select="...some other value or node-set
generating expression"/>
<xsl: variable name="var1" select="...some other other value or
node-set generating expression"/>
<xsl: variable name="var1" select="...another value or node-set
generating expression"/>
<xsl:choose>
<xsl:when test="@mode eq 'mode1'">
<xsl:apply-templates select="$nodetree" mode="mode1">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:when test="@mode eq 'mode2'">
<xsl:apply-templates select="$nodetree" mode="mode2">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:when test="@mode eq 'mode3'">
<xsl:apply-templates select="$nodetree" mode="mode3">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:when test="@mode eq 'mode4'">
<xsl:apply-templates select="$nodetree" mode="mode4">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:when test="@mode eq 'mode5">
<xsl:apply-templates select="$nodetree" mode="mode5">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:when test="@mode eq 'mode6'">
<xsl:apply-templates select="$nodetree" mode="mode6">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates select="$nodetree" mode="modeX">
<xsl:with-param name="param1" tunnel="yes" select="$var1"/>
<xsl:with-param name="param2" tunnel="yes" select="$var2"/>
<xsl:with-param name="param3" tunnel="yes" select="$var3"/>
<xsl:with-param name="param4" tunnel="yes" select="$var4"/>
</xsl:apply-templates>
</xsl:otherwise>
</xsl:choose>
...
And there is here only 7 modes and 4 parameters, instead, if the
apply-templates could be computed, I would have liked to possibly
have something less redundant, for any number of modes and
parameters, more like
...
<xsl:apply-templates select="$nodetree" mode="@mode">
<xsl:with-param name="param1" tunnel="yes" select="...some value
or node-set generating expression"/>
<xsl:with-param name="param2" tunnel="yes" select="...some other
value or node-set generating expression"/>
<xsl:with-param name="param3" tunnel="yes" select="...some other
other value or node-set generating expression"/>
<xsl:with-param name="param4" tunnel="yes" select="..another value
or node-set generating expression"/>
</xsl:apply-templates>
...
It seems that it could save space, variables, design time, run
time, typos, errors, as well as ease maintenance and update (e.g
adding mode7 and forgetting to add another xsl:when clause for it
...), while increasing readability.
Are there more elegant ways to handle mode selection? Can this be
a useful use-case to support allowing "mode" to be computed
somehow, in future XSLT updates?
Thank you,
ac
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
|
|