XML e dintorni

SilverLight HelloWorld!

Omar Damiani — Mon, 07 Apr 2008 15:07:36 GMT

Oggi, dopo che ho ultimato una piccola applicazione con un leggero anticipo, mi sono autopremiato provando a fare qualcosa per la prima volta con SilverLight.

Già ho avuto modo di poter vedere cosa si può fare, ma era ora di poter "sporcarsi le mani" e capire se non altro COSA si deve fare per produrre QUALCOSA con SilverLight.

Non essendo ancora riuscito a scaricare il libro gratuito (dei 3, quello di SilverLight è proprio quello che mi da errore), e non trovando l'email di Andrea, era ancora a totale digiuno.

Allora ho cercato sulla Rete finchè mi sono imbattuto nel tutorial di un certo (cit.) Scott Guthrie.

E' proprio quello che cercavo per cominciare.

Visual Studio 2008 ce l'ho già installato, quindi scarico i SilverLight Tools for VS Beta 1 e seguo il tutorial.

Dopo circa 10 minuti avevo già fatto la mia prima applicazione SilverLight, bello!

Devo dire di essere molto soddisfatto e divertito, peccato solo che negli ambienti dove bazzico il Framework 3.5 sia ancora abbastanza lontanuccio...

Però già il fatto che, almeno in locale posso sviluppare per me vuol dire già tantissimo.

Grande SilverLight...da oggi si apre quindi un'altra sfida...

Web Service: "There is an error in XML"

Omar Damiani — Wed, 19 Sep 2007 21:56:07 GMT

Ho combattuto per tutto il giorno con questo errore, per poi risolverlo con un giochino.

Il discorso è in sè molto semplice: ho un web service che, dopo qualche peripezia su SAP, mi ritorna una classe neanche troppo complessa ovviamente serializzata.

Richiamando il webmethod da client però ottenevo il fastidioso errore all'oggetto del post: "There is an error in XML..."

Facendo la chiamata in locale invece funzionava tutto e se, all'interno dello stesso webmethod mi mettevo a spulciare nella stringa, mi sembrava di avere un xml perfetto.

Cosa fare allora?

Beh...premettiamo che non sapevo una cosa abbastanza pesante: non sapevo che i test in locale dei Web Service sono fatti in GET, mentre il loro utilizzo viene correttamente svolto tramite SOAP.

A mio modo di vedere questo rende pressochè inutile il test in locale del web service se non per sapere se il deploy sia andato a buon fine...

Detto questo per testare un web service da remoto ho trovato di vitale importanza Web Service Studio (link su GotDotNet che non ho capito bene se e quando chiude...).

Con questo gingillino è possibile richiamare i metodi di un webservice vedendo effettivamente qual'è la richiesta e la risposta SOAP anche, e sopratutto oserei dire, in presenza di errore. Fantastico.

Quindi ci ho messo ben poco a capire che la stringa di ritorno era farcita da tanti bei ";#x0" (o qualcosa di simile, scusate l'imprecisione), in pratica degli spazi che venivano codificati in quel modo rendendo illegibile la stringa (il motivo in realtà mi è oscuro).

Allora ho pensato a qualche problema con la serializzazione. Questo ERA il mio codice:

<WebMethod()> _
Public Function HelloWorld() As String
    Dim a As New Class1
    a.Nome = "Omar"
    a.Cognome = "Damiani"

    Dim strm As New IO.MemoryStream
    Dim writer As New System.Xml.XmlTextWriter(strm, System.Text.Encoding.UTF8)
    Dim serializer As New Serialization.XmlSerializer(GetType(Class1))

    serializer.Serialize(writer, a)
    Dim sRet As String
    sRet = System.Text.Encoding.UTF8.GetString(strm.GetBuffer())
    Return sRet

End Function

Morale della favola: mi è bastato aggiungere un fantastico Trim alla riga colorata:

sRet = System.Text.Encoding.UTF8.GetString(strm.GetBuffer()).Trim

Et voilà!

In realtà per essere sicuro di non ottenere brutte sorprese ho completato il tutto passando prima da un oggetto XmlDocument, in questo modo se per qualsiasi motivo ottengo una stringa che potrebbe generare un errore XML, lo vengo a sapere prima perchè il web service solleverà un errore 500 o un'eccezione nel saggio caso in cui abbiate deciso di gestirlo:

Dim x As New XmlDocument
x.LoadXml(sRet)
Return x.OuterXml

Un promemoria: JS in XSLT

Omar Damiani — Fri, 26 Jan 2007 11:06:00 GMT

Questo è un promemoria per me, ma che magari serve a qualcuno...

Se vogliamo inserire del codice JS in un foglio di stile (XSLT) occorre inserirlo in un <CDATA/> altrimenti vengono a galla tutti gli errori di encoding dei caratteri (che inevitabilmente si presentano nel codice, ad esempio "&&" come operatore AND).

Qundi:

<xsl:text disable-output-escaping="yes">
<![CDATA[

function FaiQualcosa()
{
alert('Hello World!');
}

</SCRIPT>
]]>

</xsl:text>

Script negli XSL

Omar Damiani — Mon, 03 Apr 2006 13:24:00 GMT

Vi sarà capitato, se lavorate con i file XSL, di voler incrementare le variabili.

Cominciamo subito con il dire che il valore di una variabile non è...variabile (perchè le avranno chiamate xsl:variable e non xsl:constant rimane, per me, un mistero).

In realtà, come in tutti gli ambiti informatici, ci sono dei workaround per raggiungere il risultato (ne cito due, uno dei quali è di mio fresco apprendimento):

Usare i template (questo è un workaround davvero e potrebbe non fare al caso vostro nel 75% dei casi)
Usare gli script xsl (tag msxsl:script), questo funziona invece nel 99% dei casi, vedrete dove si nasconde quell'1% (guardacaso io ci sono dentro )

Perchè i template potrebbero non fare al caso vostro?
Beh...potrei sbagliarmi e sfuggermi qualcosa, ma davvero non capisco come un template che incrementi una variabile, possa servire ad incrementare una variabile CONTINUAMENTE magari all'interno di un ciclo.

Se poi si include che il template risponde più alla definizione di Procedura che non a quella di Funzione (per chi fosse a digiuno di definizioni diciamo che è la stessa differenza che passa tra una Sub e una Function in VB.Net )...

Ma veniamo alla parte più interessante: il tag msxsl:script.

Per utilizzarlo occorre prima dichiarare che utilizzeremo il suo namespace (msxsl) in questo modo:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt">

Ora siamo liberi di scrivere il nostro script, nel linguaggio che vogliamo:

<msxsl:script language="JScript" implements-prefix="user">
var indice=0;

function Incrementa()
{
indice=indice+1;
return indice;
}
</msxsl:script>

Io solitamente inserisco questo tag sotto quello di apertura (xsl:stylesheet) ma prima di quello di template (xsl:template), non ho provato ad inserirlo all'interno del template, ma non credo sia comunque logicamente corretto.

Avrete notato che a questo punto però ho utilizzato anche un altro namespace: lo "user", e allora ci tocca dichiararlo nell'apertura che quindi diventa:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt"
xmlns:user="http://miodominio.com/miosito">

Ora: come utilizzare questa funzione dal nostro XSL?

Beh...niente di più facile: basta un bel tag xsl:value-of:

<xsl:value-of select="user:Incrementa()"/>

Dato che la variabile (questa volta davvero Variabile) viene inizializzata una volta al valore 0 e poi incrementata, tutte le volte otterremo il suo valore incrementato (stile contatore).

Ovvio che questo trucco può servire ad inserire altre, e più interessanti, funzioni...

Come dite?
Ah...a cosa si riferisce quell'1%?

Beh...al fatto che Sharepoint, che "ben" si integra con tecnologie XML e .Net, purtoppo blocca il fantastico tag msxsl:script...

Quindi...buon divertimento per chi sviluppa su web "libero"...