Edited in a feeble attempt to clarify. The system converts XML into another XML via the XSL processor.
I’m doing some XSL rule stuff for a machine that has plug-in cards. The cards will supply their own XSL rules to the main host, which in turn will colate these into one super-XSL file to be processed by itself, and also sent over to web browsers who’ve HTTP’d onto the machine. The browser is used to set configuration items for the machine, and the XSL is there to change and/or hide and/or unhide some of the XML. To simplify my query here, I’ve invented a small example.
When a user configures an item to be of type B, (a choice of several such as A, B, C, …), then the next two items are to be changed (in some way) too. In the real deal, there’s an attribute “hidden” set to true or false, and also child elements which are set. The next two items in the real thing are to be hidden, and also child elements changed.
When the user changes the item from a type B to say a type A, then I need to work out which other nodes need to have their ‘hidden’ attribute set to false. The user will change the child elements as they see fit.
All of this is “circular”, and ordered, so if a node is set to type B, and it’s the last node (no following-sibling’s) then the affected nodes are the first in the set. (In XPath terms, if node[4] is type B, then nodes [1] and [2] are to be hidden and changed).
So, for my example here, I have as an input XML:
<topline>
<midline type="A" name="mid1" hidden="false"><source name="off"/></midline>
<midline type="B" name="mid2" hidden="false"><source name="input 1"/></midline>
<midline type="A" name="mid3" hidden="false"><source name="off"/></midline>
<midline type="A" name="mid4" hidden="false"><source name="off"/></midline>
</topline>
and the XSL will change this to:
<topline>
<midline type="A" name="mid1" hidden="false"><source name="off"/></midline>
<midline type="B" name="mid2" hidden="false"><source name="input 1"/></midline>
<midline type="A" name="mid3" hidden="true"><source name="input 1"/></midline>
<midline type="A" name="mid4" hidden="true"><source name="input 1"/></midline>
</topline>
Now if the user changes his mind, and changes mid2 to be a type A:
<topline>
<midline type="A" name="mid1" hidden="false"><source name="off"/></midline>
<midline type="A" name="mid2" hidden="false"><source name="input 1"/></midline>
<midline type="A" name="mid3" hidden="true"><source name="input 1"/></midline>
<midline type="A" name="mid4" hidden="true"><source name="input 1"/></midline>
</topline>
then the XSL will unhide the circular following siblings of mid2, so result should be:
<topline>
<midline type="A" name="mid1" hidden="false"><source name="off"/></midline>
<midline type="A" name="mid2" hidden="false"><source name="input 1"/></midline>
<midline type="A" name="mid3" hidden="false"><source name="input 1"/></midline>
<midline type="A" name="mid4" hidden="false"><source name="input 1"/></midline>
</topline>
It is this second step I am struggling with. What I’ve done to solve it is, to me, rather ugly but perhaps unavoidable given what I’m trying to achieve isn’t really XSL friendly.
What I’ve landed up doing :
<xsl:for-each select="topline">
<xsl:for-each select="midline">
<xsl:variable name="masterPosition" select="position()"/>
<xsl:choose>
<xsl:when test="@type='B'>
hide the next two nodes. This is easy:
translate($masterPosition, '1234', '2341')
works nicely.
</xsl:when>
<xsl:otherwise>
<xsl:variable name="prior1" select="translate(masterPosition, '1234', '4123')"/>
<xsl:variable name="test1" select="../midline[$prior1]/source[1]/@name='off'"/>
this second line doesn't work: I only get the first node, always.
So instead I have
<xsl:variable name="test2">
<xsl:choice>
<xsl:when test="$masterPosition='1'"><xsl:value-of select="../midline[4]/source"/></xsl:when>
and so on for the other masterPositions
</xsl:choice>
</xsl:variable>
and this is repeated for a few other variables, one each for each relevant
prior position and for the fields I need to change. I then use these
variables to change the XML - there's something in the main machine's
processing to enable this, I believe it is non-standard, so please ignore:
(At least it doesn't run against Xalan).
<set key={$test2}/@hidden, value="false")/>
</xsl:otherwise>
</xsl:choose>
<xsl:for-each>
</xsl:for-each>
Is there a more elegant way of doing this that you can think of? If not, don’t worry, I believe my hack will work, and also shouldn’t consume too many MIPS.
I can’t use <xsl:key> as our system doesn’t cope: we have multiple XSL sources which get colated into one, and the colation script (out of my control) simply doesn’t understand <xsl:key>, so if there is a solution using keys, I can’t use it.
Thanks
Richard
Here’s one way to do what you want, without keys, based on template matching:
For your sample input, the output would be:
Note that your description contradicts your sample output – this is what you would get when strictly following your description, unless I misunderstood you.
The
<xsl:with-param>is used to pass in the two nodes that are the “circular preceding-siblings” (or the empty node-set in case of@type=B'nodes).The template
<xsl:template match="midline" mode="source">uses that parameter: if it is there, it checks your condition (i.e. one of them is@type='B'and it is not@mode='off').If such a node exists, it copies its
<source>, else it copies the original<source>.