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.
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
- Silverlight e versioni CLR, il 28 agosto 2007 alle 13:49
- Intercettare il reciclo di un'applicazione ASP.NET, il 25 settembre 2006 alle 22:42
- User e custom controls, WebParts, il 15 giugno 2006 alle 20:52
- Capitolo 10 tutto su ObjectDataSource, il 6 giugno 2006 alle 23:03
- ASP.NET 2.0 per tutti: capitolo 9 pronto, il 28 maggio 2006 alle 22:55
- Gestione dei Threads in ASP.NET, il 19 aprile 2006 alle 21:36