so che questa domanda è vecchio, ma tra tutte le risposte, mi manca uno che è un approccio comune per questo caso d'uso in fase di sviluppo XSLT.
sto immaginando che il codice mancante dalla OP simile a questa:
<xsl:template match="category">
<xsl:choose>
<xsl:when test="categoryName !=null">
<xsl:value-of select="categoryName " />
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="other" />
</xsl:otherwise>
</xsl:choose>
</category>
E che l'ingresso simile a questa:
<categories>
<category>
<categoryName>Books</categoryName>
</category>
<category>
<categoryName>Magazines</categoryName>
<categoryName>Periodicals</categoryName>
<categoryName>Journals</categoryName>
</category>
<category>
<categoryName><!-- please fill in category --></categoryName>
</category>
<category>
<categoryName />
</category>
<category />
</categories>
Ie, suppongo non ci può essere pari a zero , vuoto, singolo o multiplo categoryName
elementi. Affrontare tutti questi casi usando i costrutti dello stile xsl:choose
o, in altre parole, imperativamente, diventa rapidamente disordinato (ancor più se gli elementi possono essere a livelli diversi!). Un tipico linguaggio di programmazione in XSLT è l'uso di modelli (da cui la T in XSLT), che è una programmazione dichiarativa, non imperativa (non si dice al processore cosa fare, basta dire quello che si vuole produrre se sono soddisfatte determinate condizioni). Per questo caso d'uso, che può essere simile a quanto segue:
<!-- positive test, any category with a valid categoryName -->
<xsl:template match="category[categoryName[text()]]">
<xsl:apply-templates />
</xsl:template>
<!-- any other category (without categoryName, "null", with comments etc) -->
<xsl:template match="category">
<xsl:text>Category: Other</xsl:text>
</xsl:template>
<!-- matching the categoryName itself for easy handling of multiple names -->
<xsl:template match="categoryName">
<xsl:text>Category: </xsl:text>
<xsl:value-of select="." />
</xsl:template>
questo funziona (con qualsiasi versione XSLT), perché il primo ha una precedenza più alta (ha un predicato) di cui sopra. Il modello di corrispondenza "fall-through", il secondo, prende tutto ciò che non è valido. Il terzo quindi si occupa di emettere il valore categoryName
in modo corretto.
Si noti che in questo scenario non v'è alcuna necessità di abbinare specifially categories
o category
, perché il processore elabora automaticamente tutti i bambini, a meno che non diciamo altrimenti (in questo esempio, il secondo e il terzo modello di non elaborare ulteriormente i bambini , perché non c'è xsl:apply-templates
in loro).
Questo approccio è più facilmente estendibile dell'approccio imperativo, poiché gestisce automaticamente più categorie e può essere espanso per altri elementi o eccezioni semplicemente aggiungendo un altro modello corrispondente. Programmazione senza if-branches.
Nota: non esiste una cosa come null
in XML.C'è xsi:nil, ma questo è usato raramente, specialmente raramente in scenari non tipizzati senza uno schema di qualche tipo.
si può ampliare l'esempio di codice? –
A seconda del caso d'uso, probabilmente non si vuole usare 'xsl: when' per i test del nodo. Considera ' ...' insieme a ' ...'. Il processore prenderà quindi le decisioni corrette per te e non avrai più bisogno di scrivere la logica di business in nidificato 'xsl: choose'. In molti casi, l'uso di modelli corrispondenti semplifica la scrittura di fogli di stile. –
Abel