Premetto che non sono un mostro di xslt, lo ho fino ad ora utilizzato per passare da XML a html, file excel etc etc, ma non lo avevo mai utilizzato per trasformare un file XML
Dopo avere perso 10 min facendo alcune prove che non mi hanno portato da nessuna parte ho ripreso in mano uno dei vari libri di XML/XSLT e mi sono detto, meglio ristudiare un poco.
Il fatto è che se si vuole trasformare un xml ad esempio cambiando il nome di un nodo si ragiona in un modo un po differente rispetto a come si farebbe per trasformare in un file HTML. Iniziamo quindi con un semplice problema, ho questo file xml
<root>
<mynode id="1">
<sn subid="1" />
<sn subid="2" />
<sn subid="3" />
</mynode>
<mynode id="2">
<sn subid="1" />
<sn subid="2" />
</mynode>
</root>
Voglio semplicemente cambiare il nome di un nodo, ad esempio tutti i nodi mynode debbono cambiare nome e diventare myNewNode. Partiamo inizialmente da un XSLT che reputo "base" che non fa altro che copiare tutto il file senza modificazioni, da questo si può partire.
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()" />
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()" />
</xsl:copy>
</xsl:template>
<xsl:template match="mynode">
<myNewNode>
<xsl:apply-templates select="@*|node()" />
</myNewNode>
</xsl:template>
</xsl:stylesheet>
Come potete vedere abbiamo solamente aggiunto una regola per effettuare un match dei nodi di nome mynode, questa volta non si utilizza l'istruzione xsl:copy, ma invece si cambia il nome del nodo.
Questo semplice esempio è un buon punto di partenza per capire come modificare file XML tramite XSLT, spero che vi sia piaciuto.
Alk.
Ho iniziato parlando della gestione delle stringhe e del CLR profiler, spero che il materiale possa piacervi.
Continuate a controllare il sito di dotnetmarche, molto presto verranno pubblicati i link.
Alk.
Le buone pratiche di programmazione consigliano di inserire delle asserzioni nelle proprie classi, ma cosa succede quando poi testiamo il nostro codice con NUNIT? Il problema è che al fallimento di una asserzione il test mostra la classica messagebox di avvertimento e purtroppo l'esecuzione si ferma fino a che l'utente non interviene premendo un bottone.
La soluzione a questo problema è disabilitare i trace listener standard nel web.config del progetto NUNIT.
<trace autoflush="false" indentsize="4">
<listeners>
<clear/>
</listeners>
</trace>
</system.diagnostics>
In questo modo al fallimento di una asserzione i vostri test non si interromperanno. Se volete comunque vedere le asserzioni fallite è possibile utilizzare l'oggetto standard ConsoleTraceListener in questo modo.
<SetUp()> Public Sub Init()
If (Not Trace.Listeners.Contains(Listener)) Then
Trace.Listeners.Add(Listener)
End If
End Sub
In questo modo tutti i messaggi di trace standard del .NET, che comprendono anche i messaggi generati dal fallimento delle asserzioni standard, verranno ridirezionati nella console e sono quindi visibili nella GUI del nunit.
Purtroppo per ragioni a me sconosciute se si inserisce il ConsoleTraceListener dal web.config e non in maniera programmatica non funziona, mah....
Alk.
Alk.
Inoltre per blog principalmente tecnici quello che veramente è importante non è il layout o l'aspetto grafico ma il contenuto, penso che questo stile sia leggero e leggibile e non mi dispiace.
Prossimamente se ho tempo vedrò magari di mettere mano al css per capire se si può comunque formattare meglio il menu a sinistra che comunque mi pare troppo scarno.
Attendo commenti.
Alk.
Back Next