blogs.ASPItalia.com

Silverlight e versioni CLR

Cristian "Ricciolo" Civera — Tue, 28 Aug 2007 13:46:00 GMT

E' un po' che voglio scrivere questo post, perch� il dubbio mi era venuto e avevo approfondito il discorso, perci�volevo rendervi partecipi.

Ai Community Days 2 qualcuno aveva chiesto se si poteva sfruttare il CLR di Silverlight anche fuori dal browser. In teoria la risposta � s�, perch� il CLR � una versione 2.1, basata sulla 2.0 appunto, ma limitata togliendo classi considerate superflue per browser client o eliminando overloads a metodi che occupano istruzioni IL solo per favorire il programmatore. Alcune classi invece sono rimaste. Per esempio mscorlib ha System.Console, la reflection, la parte di serializzazione,�collezioni ecc.

A confermare la mia ipotesi � questo tizio che prendendo in esempio un'applicazione di Rotor ha creato una Console application runner di nome agx.exe.

Per quanto riguarda invece avere un exe a se stante, come si pu� avere in Flash, Silverlight � un ActiveX di nome AgControl Type Library in�npctrl.dll che pu� essere usato in applicazioni standalone. A parte che non vedo il motivo di usare Silverlight (a questo punto meglio usare il .NET Framework normale), nasce comunque un problema serio.

Per ogni processo � possibile avere funzionante un'unica versione del Framework, perci� in scenari di addin e plugin succede che se una dll sviluppata per la versione 1.x viene caricata in un processo con attivo il CLR 2.0, questa�viene forzatamente eseguita con�la 2.0. In questo caso non dovrebbero esserci problemi; ce ne sono nel caso avvenga il contrario, con un "downgrade" di un componente dalla versione 2.0 alla 1.x. Questo � un problema non di poco conto e che fino adesso forse ha frenato lo sviluppo di estensioni per applicativi come la shell o Internet Explorer.
Con Silverlight inoltre, questa complicazione si fa ancora pi� probabile: poniamo di�aprire in IE una pagina con Silverlight 1.0, poi un'altra con Silverlight 1.1, poi in un futuro un'altra con un ipotetico Silverlight 2.0. Quale versione del CLR parte? La risposta sarebbe la versione�del primo "applicativo" che � stato carico.

Fortunamente questo problema � stato risolto e a partire da Silverlight, quindi anche con i futuri CLR, due�runtime possono convivere nel medesimo processo. Silverlight in particolare pu� coesistere con gli attuali CLR 1.0, 1.1 e 2.0. Ogni CLR lavora per conto suo, ha un suo GC e non condivide la memoria.�In questo post viene spiegata la soluzione tramite un video.

Tags: .NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, Silverlight, Silverlight 2.0, XAML

Continua a leggere Silverlight e versioni CLR.

Intercettare il reciclo di un'applicazione ASP.NET

Cristian "Ricciolo" Civera — Tue, 26 Sep 2006 07:27:00 GMT

Qualche tempo fa parlai del reciclo degli AppDomain delle�applicazioni ASP.NET. Sviluppando WebXaml ho avuto la necessit� di chiudere delle risorse durante la chiusura dell'AppDomain. Non esiste (almeno che io conosca) un modo per conoscere quando ci� avviene; intercettare l'evento DomainUnload della classe AppDomain non � appropriato perch� � troppo tardi per eseguire le operazioni di scarico.

Possiamo per� implementare l'interfaccia IRegisteredObject e registrarla in qualsiasi momento tramite HostingEnvironment.RegisterObject. Quando viene richiesto al runtime di ASP.NET di scaricare l'AppDomain, viene chiamato, per tutte le classi registrate, il metodo Stop(false). Successivamente viene accodato nel thread pool un ulteriore chiamata al metodo Stop(true) e�finalmente scaricato l'AppDomain con Unload.

public class MyClass : IRegisteredObject<br />{<br />    void IRegisteredObject.Stop(bool immediate)<br />    {<br />         // Disposing...<br />        HostingEnvironment.UnregisterObject(this);<br />    }<br />}

E' nella prima chiamata che ho trovato il punto pi� appropriato per chiudere le mie risorse.

UPDATE: mi � venuto in mente che ovviamente esiste l'evento Application_OnEnd, ma va inserito nel global.asax e non � quindi "pluggabile".

Tags: .NET Framework, .NET Framework 2.0, ASP.NET, ASP.NET 2.0

Continua a leggere Intercettare il reciclo di un'applicazione ASP.NET.

User e custom controls, WebParts

Cristian "Ricciolo" Civera — Thu, 15 Jun 2006 18:52:00 GMT

Ed anche questo capitolo � terminato. Mi rendo conto che gli argomenti proposti in questo capitolo sono molto vasti.

Per�user controls credo aver avuto un bel approccio pratico ad esigenze frequenti. Sui custom controls esistono libri interi, perch� volendo ci sarebbe da discutere per ogni controllo presente in ASP.NET 2.0, studiando come hanno implementato�data binding, ViewState, datasource ed integrazione con Visual Studio 2005. Per questi ho cercato quindi di gettare le basi utili per sviluppare un controllo personalizzato, in particolar modo quelli composti che nella mia esperienza mi sono ritrovato maggiormente a sviluppare.

Stiamo un po' riorganizzando i capitoli per delineare meglio un percorso logico che congiunga gli articoli, quindi � facile che troverete i capitoli spostarsi o cambiare di nome.

Tags: ASP.NET, ASP.NET 2.0, ASP.NET 2.0 per tutti, Custom Control, User Control

Continua a leggere User e custom controls, WebParts.

Capitolo 10 tutto su ObjectDataSource

Cristian "Ricciolo" Civera — Tue, 06 Jun 2006 21:19:00 GMT

O quasi... E' l'argomento principe poich� ormai tutti sappiamo che il miglior approccio all'accesso ai dati � interfacciarsi con le classi business.
L'intero capitolo credo che abbia abbastanza un approccio pratico, basato su esigenze che si possono incontrare, come le master/details e d� spazio anche ad un DataControlFied personalizzato.

Purtroppo non ha trovato spazio alla creazione di un DataSource personalizzato. E' piuttosto lungo da spiegare in effetti e soprattutto non � una cosa da tutti i giorni.
Il problema � che mi sono preso cos� bene che ho sviluppato un FileSystemDataSource, per l'accesso al file system, e un FtpDataSource, per l'accesso ad un host FTP. Entrambi che implementano sia IDataSource che IHierarchicalDataSource e quindi utilizzabili sia con TreeView/Menu, sia con GridView e fratelli.

Probabilmente li lascer� comunque nel codice che daremo insieme al libro.

Il loro utilizzo � alquanto semplice

&lt;aspitalia:FtpDataSource ID=&quot;ftp1&quot; runat=&quot;server&quot; UsePassive=&quot;true&quot; Host=&quot;ftp://localhost&quot; /&gt;<p />&lt;asp:TreeView ID=&quot;treeView1&quot; runat=&quot;server&quot; DataSourceID=&quot;ftp1&quot;&gt;<br />    &lt;DataBindings&gt;<br />        &lt;asp:TreeNodeBinding DataMember=&quot;Directory&quot; TextField=&quot;Name&quot; ImageUrl=&quot;~/Images/folder.gif&quot; /&gt;<br />        &lt;asp:TreeNodeBinding DataMember=&quot;File&quot; TextField=&quot;Name&quot; ImageUrl=&quot;~/Images/file.gif&quot; /&gt;<br />    &lt;/DataBindings&gt;<br />&lt;/asp:TreeView&gt;

Tags: ASP.NET, ASP.NET 2.0, ASP.NET 2.0 per tutti, Databinding

Continua a leggere Capitolo 10 tutto su ObjectDataSource.

ASP.NET 2.0 per tutti: capitolo 9 pronto

Cristian "Ricciolo" Civera — Sun, 28 May 2006 20:55:00 GMT

Eh s�, sono partito gi� molto avanti :-) affrontando i controlli�DataSource e�i controlli�composti che ne usufruiscono. E' un capitolo dove ho puntato pi� ad approfondire i concetti legati al binding e al nuovo approccio introdotto in ASP.NET 2.0. Non tratto quindi come stilizzare GridView e compagni, visto che il libro non � di grandi dimensioni, meglio parlare delle cose importanti.

Il prossimo si concentra su ObjectDataSource, personalizzazione dei DataSource e template. Le intenzioni sono buone e per adesso sono nella tabella di marcia, speriamo bene.

Tags: ASP.NET 2.0 per tutti

Continua a leggere ASP.NET 2.0 per tutti: capitolo 9 pronto.

Gestione dei Threads in ASP.NET

Cristian "Ricciolo" Civera — Wed, 19 Apr 2006 19:36:00 GMT

Devo fare una correzione riguardante a ci� che ho detto nella mia sessione tenuta durante i community days.

Parlando del worker process di ASP.NET ho spiegato come il motore gestisce le richieste con�una lista di 20 thread gi� pronti. Nel dirla mi � venuto un dubbio e sono andato�controllare. In ASP.NET 2 i threads nella impostazione di default, sono 100 per CPU cos� come i threads IO.
Questa impostazione � modificabile nel machine.config attraverso la sezione processModel. Normalmente � presente un unico attributo autoConfig, ma � possibile impostare manualmente maxWorkerThreads e maxIoThreads.
Se non ci credete, chiamate System.Threading.ThreadPool.GetMaxThreads e vedrete quanti threads sono stati allocati dal motore di ASP.NET.

Questa modifica � importante. Aumentare o diminuire il numero dei threads�pu� incidere sulle performance delle applicazioni. Un numero troppo basso pu� limitare il numero delle richieste che l'applicazione pu� soddisfare, un numero troppo alto pu� sprecare cicli di CPU per il context switch tra un thread e l'altro e peggiorare ancor di pi� il worker process.

C'� da considerare comunque che nelle applicazioni web alcune richieste restano in attesa, magari perch� invocano webservices o aspettano una risposta dal database cos� da non pesare sul processo di ASP.NET, ma comunque impegnando un thread.

Chieso scusa�per non essere stato preciso.

Tags: ASP.NET, ASP.NET 2.0, HttpRuntime, IIS, Windows Server

Continua a leggere Gestione dei Threads in ASP.NET.

RealTime Web Event Provider

Cristian "Ricciolo" Civera — Tue, 14 Mar 2006 21:57:00 GMT

Nel tempo libero sto sviluppando un piccolo tool in grado di mostrare in real time gli eventi generati da un'applicazione ASP.NET 2.
Marco ha parlato in questo articolo come sviluppare un provider che gestisce gli eventi web�e anch'io ho fatto lo stesso usando .NET remoting per comunicare tra l'applicazione web e windows.
Eccovi uno screenshot parziale di quello che sto facendo:

Niente di particolare, ma nelle mie intenzioni c'� la possibilit� di attivare alerts e filtri sugli eventi e di estendere il sistema di health monitoring per un'analisi pi� approfondita, ovviamente se ne sar� capace :-D

Vi far� sapere...

Continua a leggere RealTime Web Event Provider.

Tasks per MSBuild

Cristian "Ricciolo" Civera — Tue, 14 Feb 2006 17:46:00 GMT

MSBuild � una novit� importante della versione 2 del Framework .NET e�molto comoda,�tanto da spingere Microsoft a rendere disponibile anche una versione 1.

Naufragando tra i miei feeds�ho trovato questo progetto open source che raccoglie una serie di tasks per eseguire le funzionalit� pi� disparate quando lanciamo msbuild.

Ce ne sono di carini come la possibilit� di eseguire operazioni su sourcesafe, creare virtual directory e application pool, creare zip ed�eseguire operazioni sui window services.

Continua a leggere Tasks per MSBuild.

Bindare Nullable Types in automatico

Cristian "Ricciolo" Civera — Mon, 30 Jan 2006 21:08:00 GMT

Oggi Andrea "pota pota"�ha fatto una domanda molto interessante nel forum riguardo ad un problema che non avevo ancora incontrato. GridView, DetailsView, FormView danno la possibilit� di auto generare i fields da mostrare in funzione della sorgente dati, ma nell'esempio portato caricava una classe contenente dei membri nullabili (Nullable types), caratteristica introdotta in .NET 2 poich� si basa sulla struttura Nullable generica. Questi membri per�non vengono mostrati.

I controlli si appoggiano a TypeDescriptor.GetProperties�per ottenere le propriet� di un tipo (che�implementa eventualmente ICustomTypeDescriptor) e le filtra interrogando il metodo IsBindableType. Questo fa s� che vengano scartati membri diversi dai tipi primitivi, date o stringhe. Purtroppo il Type di un membro nullabile � Nullable generico e non il tipo di valore che si sta rendendo nullabile.

Fortunamente il metodo � sovrascrivibile e si pu� fargli digerire anche i nullable types:

public class MyGridView : GridView { <br /><br />    public override bool IsBindableType(Type type) {<br />        return !(!base.IsBindableType(type) &amp;&amp; !type.IsGenericType);<br />    }<br /><br />}

Spero possa esservi utile in futuro ;-)

Continua a leggere Bindare Nullable Types in automatico.

ViewState e validazione eventi

Cristian "Ricciolo" Civera — Sat, 10 Dec 2005 15:47:00 GMT

Vi assicuro che non vivo solo di ViewState anche se mi ritrovo di nuovo a parlarne :-)

Ci sono altre novit� nella versione 2 di cui non avevo ancora letto niente. Vi sarete magari trovati di fronte ad un nuovo campo nasconto della form di nome __EVENTVALIDATION. Si pu� controllare questo campo tramite la propriet� Page.EnableEventValidation e fa s� che venga controllato se eventuali postbacks sono validi.

Per esempio, se abbiamo una tabella dodata per ogni riga di un pulsante di cancellazione spesso si sfrutta il CommandName o il CommandArgument per identificare il record. Ma cosa succede se qualche malintenzionato fa il POST di una form con un __EVENTTARGET modificato? Potrebbe cancellare un record non di sua competenza. Certo come ci insegna Riccardo, uno strato business sottostante dovrebbe gi� prevedere questo tipo di situazione e saremmo quindi al riparo.
Ma questa architettura non sempre viene sempre utilizzata o scritta nel modo corretto, perci� ogni controllo di ASP.NET 2 richiede questo controllo. Lo possiamo fare anche dai nostri controlli custom richiamando GetPostBackEventReference con l'argomento registerForEventValidation a true�o manualmente con ClientScriptManager.RegisterForEventValidation�e validando il postback con ClientScriptManager.ValidateEvent. Se il controllo non passa verr� generata un'eccezione ArgumentException: Invalid postback or callback argument.

Ma non finisce qui. La classe Page dispone di una propriet� ViewStateEncryptionMode, di default�impostata su�Auto. Ci� significa che normalmente il viewstate � codificato BASE64 soltamente, ma qualora un controllo lo richieda con RegisterRequiresViewStateEncryption il ViewState viene criptato e non ci sar� quindi verso di decifrarlo con i normali decoder.
Chi richiede la criptazione in modo automatico in fase di Init sono i controlli: DataList, DetailsView, FormView, GridView.

Per le modalit� di criptazione guardare la sezione di web.config system.web/machineKey. Di default usa Auto (Rijndael) con chiave autogenerata isolata per applicazione.

Continua a leggere ViewState e validazione eventi.

Preview ViewState Analyzer per ASP.NET 2

Cristian "Ricciolo" Civera — Tue, 21 Jun 2005 11:41:00 GMT

Continua la mia migrazione da ASP.NET 1.x a 2 e tra questi c'� anche lo sviluppo della nuova versione del mio ViewStateAnalyzer. In questa nuova versione ho cercato di facilitare la sua configurazione, omettendo la configurazione da web.config. Ora un estensione apposita mappa sulle normali aspx ed � possibile analizzare qualsiasi Page custom.
Inoltre ora � una toolbar aggiuntiva per Internet Explorer, in questo modo lo strumento � sempre a portata di mano e mi toglie il peso di dover sviluppare funzioni di navigazione, bookmarks ecc.
Vi posto uno screenshot per avere un'idea di come uscir�poich� �ancora in fase di sviluppo

Per chi non lo sapesse questo strumento offre oltre ad un normale decoder del viewstate utilizzabile su qualsiasi pagina la possibilit� di:

visualizzare l'intero grafo dei controlli
conoscere quali hanno il viewstate abilitato/disabilitato e il loro ID
visualizzare per ogni controllo il viewstate / control state (new) con modalit� ottimizzate in funzione di strutture di salvataggio conosciute (ViewState bag ecc)
mostrare l'html generato da ogni controllo e cercarlo all'interno della pagina renderizzata (new)
conoscere gli handlers gestiti su ogni controllo con auto suggerimento di eventuali disabilitazioni di viewstate

Il tutto funziona tramite un handler che raccoglie le informazioni necessarie e le invia tramite remoting alla toolbar che � in ascolto.

Credo sia uno strumento molto utile, quindi spero di finirlo il prima possibile in modo da usarlo e renderlo il pi� stabile possibile.

Continua a leggere Preview ViewState Analyzer per ASP.NET 2.

ViewState da ASP.NET 1.x - 2.0

Cristian "Ricciolo" Civera — Fri, 10 Jun 2005 19:18:00 GMT

Non so perch� ma il ViewState � un mio pallino e mi cattura molto l'idea che ci sta dietro. Quindi vi parlo di cosa � cambiato in ASP.NET 2.

ASP.NET 1.x
Per farlo bisogna partire da cosa c'� adesso. Come saprete ogni Control ha un metodo SaveViewState che dobbiamo sovrascrivere per persistere le informazioni durante i postbacks. Il metodo base salva ci� che � contenuto nello StateBag fornito dalla propriet� ViewState, quindi spesso si ricorre a salvare elementi in questo hashtable (che piace tanto tanto a Paolo :-D). Tutto questo viene fatto ricorsivamente per tutto l'albero degli oggetti. Una volta terminato, tramite la classe LosFormatter il tutto viene serializzato in stringa e convertito in Base64 per poter esserito inserito nel value del campo nascosto __VIEWSTATE.
L'unico mezzo che abbiamo per modificare cosa e dove�persistere � sovrascrivere Page.SavePageStateToPersistenceMedium / LoadPageStateFromPersistenceMedium. Il LosFormatter lavora in modo da prendere l'intero grafo di oggetti e ricorsivamente serializzare ogni oggetto con una sua formattazione particolare. Consiste infatti nell'indicare con una lettera il tipo primitivo o conosciuto e tra < > mettere il valore a seconda del tipo. Per esempio un intero di valore 5 verr� trasformato in i<5>.
Eccovi una tabella del lavoro che fa

Tipo	Prefisso	Valore
intero	i	numero
bool	o	t oppure f
arraylist	l	valori separati da punto e virgola
hashtable	h	chiave ; valore ;
pair	p	valore ; valore
triplet	t	valore ; valore ; valore
arraystringhe	@	valori separati da punto e virgola
array	@	id del tipo numerico < valori separati da ; >
altri tipi	b	sottoserializzazione nello stesso modo. Se possiede un TypeConverter usa ConvertTo(stringa) e ConvertFrom(stringa)

Le classi Pair e Triplet sono state create per velocizzare il lavoro e perch� occupanti meno spazio rispetto ad un array. Ecco perch� nel controlli del Framework�se ne fa ampio uso. La sottoserializzazione avviene annidando i valori; per esempio questo oggetto:

new Pair("ciao", new Pair(2,3))

diventer�: p<ciao;p<i<2>;i<3>>>
Successivamente come gi� detto tutto questo viene convertito in Base64. La conversione consiste nel racchiudere un set di bytes che vanno da un range di 0 a 255 in un set di bytes che vanno da 0 a 63 e corrispondenti a caratteri trasportabili (dalla A-Z0-9+=)�della tabella ASCII US. Questa operazione comporta per� un aumento dei bytes�in ingresso di circa un terzo.

ASP.NET 2
Come gi� anticipato da Marco, il ViewState � stato affiancato dal Control State. Non c'� nessuna differenza tra i due. Entrambi infatti verrano uniti tramite un Pair di root e verranno serializzati insieme. C'ho che cambia � lo scopo: salvare le informazioni minime per il funzionamento del controllo. La particolarit� sta nel fatto che per salvare delle informazioni in questo "bag" dovremo sovrascrivere Control.SaveControlState, ma che questo non viene pi� fatto ricorsivamente. Ad indicare che il controlstate deve essere usato pochissimo, anzi, molti controlli non ne fanno uso. Infatti � necessario notificare alla Page che abbiamo bisogno di persistere queste informazioni tramite Page.RegisterRequireControlState.

Tutto questo verr� serializzato e persistito tramite Page.PageStatePersister una propriet� che possiamo sovrascrivere e che dispone di due implementazioni: HiddenFieldPageStatePersister e SessionStatePageStatePersister. I nomi dicono gi� tutto: il primo serializza e butta il tutto nel campo nascosto __VIEWSTATE e l'altro persiste nella session senza riempire la pagina da restituire al client.
L'aspetto interessante � che la scelta viene fatta sfruttando gli adaptive rendering. Per dispositivi mobile � configurato infatti di utilizzare il persister su sessione.

Ora LosFormatter�� stato sostiuito (seppure presente per motivi di retrocompatibilit�) da ObjectStateFormatter. La prima differenza sta nel fatto che non vengono pi� usati il < > per racchiudere un oggetto e non sono pi� annidati, ma "concatenati" uno dopo l'altro. Questo porta ad una riduzione dei bytes utilizzati specialmente se gli oggetti sono tanti.�Inoltre il prefisso � stato sostituito da un byte progressivo�che parte da 100 (0x65) ad indicare la tipologia di dato serializzato. Questa scelta mi sembra essere solo stilistica e fine a�nient'altro, magari mi sfugge qualcosa. La gamma dei tipi conosciuti � stata ulteriorermente migliorata ed estesa a tipi come: Unit, Char, DateTime, Color, Type. Questo per ridurre al minimo la trasformazione in stringa essendo tipi di uso comune.
Una classe importante � IndexedString. Qualora il formatter�trovi nel grafo degli oggetti di questo tipo ed � la prima volta che lo incontra, memorizza il valore in un hashtable e scriver� in output (byte)5 + stringa. La volta successiva invece scriver� (byte)31 indice di posizione dell'hashtable. In questo modo indicizza e non ripete pi� volte il valore. Questa classe viene sfruttata quando la propriet� Control.ViewState deve essere persistita.
Tutto questo verr� poi convertito come in .NET 1.x in Base64.
Il risultato di tutto questo�� una maggiore compressione del ViewState specialmente con una struttura d'albero complessa e con molti oggetti.

Tags: ASP.NET, ASP.NET 2.0

Continua a leggere ViewState da ASP.NET 1.x - 2.0.

TextBox con AutoComplete per ASP.NET 2

Cristian "Ricciolo" Civera — Thu, 09 Jun 2005 19:15:00 GMT

Potevo resistere a non fare una versione della mia carissima TextBox anche per ASP.NET 2!? Ovviamente no anche perch� il lavoro di adattamento non � stato molto. L'avevo appoggiato sulle ClientPages che dispongono di un'architettura molto simile, anzi rubata :-D

Il risultato � questo

Uguale a prima, ma sicuramente � comodissimo l'uso:

<cc1:TextBoxAC ID="TextBoxAC1" AutoCompleteMode="Server" DataSourceID="test" �� DataTextField="Capoluogo" runat="server" />

<asp:AccessDataSource ID="test" runat="server" DataFile="~/App_Data/province.mdb" �� SelectCommand="SELECT [Provincia], [Capoluogo] FROM [Province] WHERE ([Capoluogo] LIKE ? + '%')"> �<SelectParameters> ��<asp:ControlParameter Name="Capoluogo" Type="String" ControlID="TextBoxAC1" /> �</SelectParameters> </asp:AccessDataSource>

Per realizzarlo ho ereditato da DataBoundControl della quale parlavo qualche giorno fa. Automaticamente carica i dati indipendentemente dal fatto che usiate la modalit� client (tutto buttato in un array javascript) o server (uso del client callback).

Lo trovate completo di sorgenti qua.

Tags: AJAX, ASP.NET, ASP.NET 2.0, JavaScript

Continua a leggere TextBox con AutoComplete per ASP.NET 2.

Controlli web con ASP.NET 2

Cristian "Ricciolo" Civera — Tue, 07 Jun 2005 20:55:00 GMT

Oramai se sviluppate con ASP.NET avrete capito l'organizzazione dei controlli e di cosa offrono. Tutto fa a capo alla classe System.Web.UI.Control che espone le funzioni basilari. Poi se vogliamo rappresentare un tag html senza particolari carattaristiche possiamo ereditare da System.Web.HtmlControls.HtmlControl o pi� avanzato ancora da System.Web.WebControls.WebControl che aggiunge funzionalit� di Styling.

In ASP.NET 2 tutto questo � rimasto invariato; si � allargata la famiglia degli HtmlControls aggiungendo ad esempio HtmlHead, HtmlTitle o HtmlLink che ci permettono di impostare il Title o gli Styles in modo pi� semplice. Una nuova tipologia si � affiancata per metterci di utilizzare le sorgenti dati in modo dichiarativo, tramite le classi System.Web.UI.DataSourceControl e System.Web.UI.HierarchicalDataSourceControl (per sorgenti gerarchiche).

Sono state aggiunte per� anche delle classi intermedie che racchiudono logiche comuni in molti WebControl anche custom che spesso dovevamo replicare. Una di queste � CompositeControl dalla quale dobbiamo ereditare se il nostro controllo non � altro che un contenitore di altri controlli. Implementa INamingContainer quindi ci toglie il problema di eventuali conflitti di ID e si assicura di creare i controlli figli ogni qual volta si accede alla propriet� Controls e di richiamarne il databinding.

Altra classe base � BaseDataBoundControl. Un webcontrol che espone le propriet� DataSource e DataSourceID e controlla di effettuare il binding durante i postbacks o qualora non avessi chiamato manualmente il metodo DataBind. Da questa ereditano DataBoundControl e HierarchicalDataBoundControl che da come si pu� capire si occupano di caricare i DataSource collegati e ne fanno il select. Il metodo pi� importante di cui dispongono � PerformDataBinding. Ci basta sovrascrivere questo membro e ci verr� passata la sorgente gi� risolta come IEnumerable che possiamo iterare ed eventualmente accedere ai valori tramite DataBinder.GetPropertyValue. Non dovremo preoccuparci d'altro e di questa comodit� ne fanno uso i vari ListControl (DropDownList, CheckBoxList ecc). Se CompositeControl � pensato per controlli composti, ma senza dati, esiste il corrispettivo CompositeDataBoundControl che unisce entrambe le cose. E' sfruttato da GridView, FormView e DetailsView che sono appunto classi che istanziano altri controlli. La particolarit� sta nel metodo astratto CreateChildControls che riceve la sorgente gi� risolta e un parametro dataBinding. Questo ci serve perch� la prima volta che viene caricata ad esempio il GridView, verr� creata la lista delle righe e caricate con i rispettivi valori. In caso di postback invece, se abbiamo il view state abilitato, dataBinding sar� a false e la dataSource sar� un intero indicante il numero di righe. Sono informazioni sufficienti per ricreare lo stesso numero di TableRow. Per il resto ci penser� il ViewState e ci consentir� di mantenere le informazioni senza andarle a riprendere dalla sorgente.

Come ho gi� detto tutta questa logica c'era gi� prima, ma ora � stata "patternizzata" e la possiamo utilizzare anche noi a seconda delle esigenze.

Tags: ASP.NET, ASP.NET 2.0

Continua a leggere Controlli web con ASP.NET 2.

AutoEventWireup con ASP.NET 2

Cristian "Ricciolo" Civera — Mon, 16 May 2005 16:15:00 GMT

Qualche tempo fa parlai dell'implementazione dell'AutoEventWiredUp di ASP.NET sottolineando come riducesse moltissimo le performance e dell'oppurtunit� di tenerlo sempre disattivato.

In ASP.NET 2 l'AutoEventWiredUp � ancora di default attivo e soprattutto Visual Studio 2005 a differenza di Visual Studio .NET 2003 lo tiene ancora attivo. Mi sono quindi�spaventato e ho verificato cosa fa:

Quando impostiamo a false la propriet� viene emesso del codice nella pagina che sovrascrive TemplateControl.SupportAutoEvents. In funzione di questa variabile ad ogni esecuzione aggancia quindi�gli eventi. La differenza sta nel fatto che tenta ancora di creare il delegate alla funzione tramite Delegate.CreateDelegate, ma ora alla funzione � possibile chiedere se generare o meno un'eccezione. Gi� questo migliora di molto le performance, inoltre mantiene un dictionary di MethodInfo (oggetti reflection) in cache cos� da non ripetere pi� l'operazione.
Per non pesare ancora sulla ricerca degli eventi alla quale agganciarsi in presenza di un metodo con�il nome corretto, viene poi in aiuto il pattern degli eventi che sfrutta un dictionary nomevento (stringa) / delegate dell'evento. Il lavoro quindi dell'uso dell'AutoEventWiredUp si limita a sfogliare il dictionary contenente i metodi della nostra classe e il dictionary degli eventi.

Insomma, ora va molto meglio anche se personalmente continuer� con l'override dei metodi che scatenano gli eventi e la disattivazione della funzione.

Tags: ASP.NET 2.0, ASP.NET

Continua a leggere AutoEventWireup con ASP.NET 2.