agosto 2003 Entries
Una delle domande più ricorrenti sul forum InfoPath è: "ma quanto costa ?" Sino ad oggi, da parte Microsoft, c'era il più stretto riserbo sull'argomento. Da pochi giorni sono stati pubblicati i prezzi. Per i più curiosi: InfoPath costerà 199 Dollari.
L'implementazione ASP.NET dei web services presenta una lacuna abbastanza importante: non permette di modificare l'encoding. Infatto, l'encoding di default è UTF-8 e non è possibile modificarlo. Questo pone non pochi problemi quando si vogliono usare caratteri speciali.
Una soluzione comunque c'è: scriversi una SoapExtension. Infatti, attraverso questo tipo di classi è possibile intercettare lo stream SOAP in tutte le sue fasi (prima e dopo la serializzazione sia in entrata che in uscita dal web server). Ho scritto quindi una classe EncodingExtension che non fa altro di modificare l'engoding del messaggio SOAP in uscita. Per provarla, potete scaricarla dal sito GotDotNet.
L'8 di agosto è stata pubblicata la versione definitiva del "Basic Profile" WS-I. Si tratta del primo documento che definisce le regole "uniche" per garantire interoperabilità fra i differenti servizi. Finalmente si è arrivati ad una decisione molto importante, secondo me la più importante, e cioè dare una risposta alla classica domanda: RPC/encoded o document/literal ?
Tanto per ricordare che cosa significano, riprendo i concetti definiti nella specifica WSDL 1.1
"If use is encoded, then each message part references an abstract type using the type attribute. These abstract types are used to produce a concrete message by applying an encoding specified by...
A volte può risultare utile che i costruttori delle classi derivate implementino una certa firma. Se fosse stato un metodo o una proprietà bastava definirli come abstract, ma il costruttore non può essere dichiarato tale.
Possiamo comunque eludere il sistema in questo modo:
abstract class Base{ protected string _message;
public Base(string message) { _message = message; }}
class Derived : Base{ public Derived(string message) : base(message) {}}
Di fatto, stiamo eliminando il costruttore di default (quello senza parametri) ma dichiarando un'unico costruttore con firma. Non è certamente una cosa complessa, ma può risultare molto utile.
La gestione dello stato attraverso ViewState agevola molto gli sviluppatori in quanto non debbono più doversi salvare le informazioni inserite nella pagina con artifici di vario genere (che i programmatori ASP ben conoscono).
Per default, VS.NET abilita questo meccanismo rendendo tutti i controlli ViewState enabled. Se da un lato è molto positivo, dall'altro bisogna prendere alcune precauzioni. Ci sono un paio di circostante nelle quale il ViewState non è, a parer mio, la scelta ottimale. La prima, più evidente, quando il controllo (es. DataGrid, DataList, Repeater, DropDownList, ecc.) contiene molti dati. Si pensi ad esempio ad una DropDownList con 100 elementi....