Di .NET e di altre amenita'

In questi giorni, dato che la beta di Vista ancora nicchia, per non so bene quale motivo, mi sono preso la briga di impiegare il mio già scarso tempo a disposizione, mettendo il naso nella beta di Monad, cui mi sono iscritto. Monad, per chi non lo sapesse è la nuova shell di Microsoft che dovrebbe debuttare con l'uscita del nuovo sistema operativo Vista, probabilmente entro la fine di quest'anno, sotto il nome di MSH.

Devo dire che sono molto affascinato da Monad, che pur presentandosi con un'interfaccia molto linux-like, dopo una breve esplorazione si rivela un ambiente di una flessibilità e potenza ineguagliabili, tanto da far impallidire facilmente anche il più sfegatato bash-ista. Prima di introdurvi al codice che voglio presentare, che in questi ho scritto per Monad, vale la pena che vi delucidi su cosa rende così potente e singolare un ambiente che a prima vista altro non è che la "solita" linea di comando.

In effetti, dopo aver digerito il primo impatto con la console, la cosa giusta da fare è di rivolgersi alla rete per cercare di capire qual'è il principio attorno cui si impernia il funzionamento di monad, perchè senza averne compreso la logica è del tutto inutile provare a trarne qualcosa di utile, dato che invariabilmente si rimarrà impigliati nell'errata interpretazione che la riga di comando impone. Monad infatti è un ambiente in tutto e per tutto ad oggetti che ha la capacità di estendere il comune concetto di "piping" che molti conoscono grazie alle shell Unix, su una dimensione ulteriore, si potrebbe dire "tridimensionale" quale sono gli oggetti di .NET. Per chiarirlo facciamo subito un piccolo esempio pratico; Aprite una console msh e scrivere quanto segue:

Ok, so bene che si tratta di uno scherzo un po' scemo, ma è molto significativo. Vediamo di spiegarlo in due parole; get-process è la cmdlet che restituisce l'elenco dei processi attivi, alla quale è possibile applicare un filtro per nome processo. In questo modo monad troverà tra tutti i processi quello che si chiama "iexplore" e su di esso chiamerà il metodo Kill(), con l'ovvio risultato di chiuderlo.

Converrete con me che questo approccio è davvero fantastico. Se si considera che qualunque cosa venga restituita da Monad è un oggetto di .NET è del tutto evidente che come tale è possibile manipolarlo con la massima libertà. Questo infatti vale allo stesso modo che per i processi attivi, anche per i file e le directory del filesystem che generano degli oggetti di tipo DirectoryInfo e FileInfo che chi ha già usato System.IO conosce bene. Se poi consideriamo che come unix insegna una shell ha sia uno stout che uno stin ecco che appare evidente che i medesimi oggetti che vengono generati da un comando di MSH possono essere passati in input ad un altro comando MSH che li potrà manipolare a piacimento. E' questo il meccanismo del "piping" che mentre in unix/linux si ferma tipicamente al semplice testo ASCII, in monad assume questa consistenza tridimensionale dell'oggetto .NET.

Ma la domanda legittima che ci si dovrebbe porre a questo punto è: ma chi è che genera questi oggetti?

In effetti potrebbe apparire a prima vista che gli oggetti restituiti in output da un comando siano "generati" dal comando stesso, ma non è esattamente così; I comandi di monad infatti sono dei "Verbs", che per essere eseguiti hanno la necessità di un provider che ne interpreti l'input e ne restituisca di conseguenza l'output. Dicendo questo mi sto in effetti muovendo su un terreno un po' scosceso, infatti quanto dico è frutto semplicemente delle mie sperimentazioni e potrebbe essere inficiato dalla limitatezza delle stesse, ma non credo di allontanarmi di molto dalla verità. In effetti i provider in Monad ci sono è sono qualcosa di molto importante, basti pensare che per l'accesso al filesystem esiste un FileSystemProvider che risponde ai comandi più comuni che si possono dare ad un filesystem.

La cosa eccezionale è che questi provider si possono scrivere in .NET con il framework 2.0 è come naturale non appena ne ho scoperto l'esistenza mi ci sono buttato a capofitto per capire come sfruttarli e ho scritto un po' di codice che vi presenterò in un paio di post.

Va detto innanzitutto che un provider per Monad è una classe .NET che estende una classe base, nel mio caso NavigationCmdletProvider e che implementa una serie di interfacce accessorie che consentono di estenderne ulteriormente le funzionalità. Così, nel caso del FileSystemProvider abbiamo che esso eredita dalla NavigationCmdletProvider che gli consente di usare i comandi "cd" e "dir" o per dirla con Monad "set-location" e "get-childitem". Lo stesso provider inoltre implementa l'interfaccia IContentCmdletProvider che gi permette di rispondere ai comandi come "get-content" (type).

Scrivere un provider per Monad quindi significa fare in modo che i comandi che normalmente si impartiscono per navigare nel filesystem possano essere usati anche per navigare in qualsiasi altra struttura gerarchica. La stessa Shell infatti già dispone di altri provider (usare get-provider per avere l'elenco completo) che rispondono a quelli che impropriamente si potrebbero chiamare "device" o "drive". Ad esempio il drive HKLM: consente di navigare all'interno del registry; ENV: nelle variabili di ambiente. E così via.

Appena ho scoperto questa caratteristica ho subito pensato di scrivere un provider e tra tutte le possibili varianti a scopo di esercizio ho deciso di realizzare un provider che risponda al drive "sql:". Come ben potete immaginare questo device consente di navigare all'interno dello schema di un database sql nel quale si abbia accesso con la windows authentication, sfruttando i comuni "cd" e "dir".

Ora è tardi è non mi sembra il caso di continuare, però prometto che a breve tornerò su questo appetitoso argomento presentandovi il codice funzionante che ho realizzato, e magari proverò anche a migliorarlo.

Che gioia, dopo 6 giorni che il corriere della UPS se la scarrozza in giro per Treviso e dintorni senza riuscire mai a venire ad un'orario tale da riuscire a trovarmi, ieri è finalmente arrivato il Welcome Kit accompagnato dai primi 2,5 KG di DVD della MSDN  Universal compresa nella Visual Studio Team Suite che Davide mi ha regalato. baciamo le mani vossignoria...

Stasera perciò mi sono inventato un gioco con mia figlia. Ho aperto tutti i pacchetti, sparpagliato i CD sul tavolo ed ho esclamato: Adesso li mettiamo tutti al loro posto... i verdi con i verdi, i rossi con i rossi e così via. E' passata un'ora ma alla fine ci siamo riusciti ed ora ogni CD è al suo posto in bell'ordine nel faldone in vero policlorurodivinile.

Apprendo ora che stamattina alle 11:30 è morto Luca Coscioni, il presidente dei Radicali Italiani e dell'omonima associazione "Luca Coscioni" per la Ricerca Scientifica.

Lo voglio ricordare con le parole che aveva dedicato a lui José Saramago, premio nobel per la letteratura:

Forse il sostegno di un semplice scrittore come me stonerà un poco, o anche troppo, nella lista delle personalità scientifiche che, con i loro nomi e il loro prestigio, suggellano le affermazioni rese da Luca Coscioni in quella sua lettera del 20 marzo, così chiara e commovente. In ogni caso, potete disporre del mio nome. Purchè la luce della ragione e del rispetto umano possa illuminare i tetri spiriti di coloro che si credono ancora, e per sempre, padroni del nostro destino. Attendevamo da molto tempo che si facesse giorno, eravamo sfiancati dall’attesa, ma ad un tratto il coraggio di un uomo reso muto da una malattia terribile ci ha restituito una nuova forza. Grazie, per questo.

Cordialmente, José Saramago

Ciao Luca. Con te se ne va un grande uomo, ma resta la speranza che ci ha dato.

Il primo meeting di XEDOTNET si sta avvicinando, ciascuno affila le sue slides, io mi preparo al debutto in qualità di conduttore dell'evento e mi sto impegnando a raccogliere le iscrizioni. Sono davvero contento del riscontro che sto ottenendo. Nonostante si tratti di uno usergroup praticamente sconosciuto sono quasi arrivato a riempire la sala che ho a disposizione e la speranza è quella di riuscirci entro breve. Invito chiunque ancora non si sia registrato a farlo al più presto perchè le adesioni stanno superando le aspettative e quindi sarò costretto a lavorare di "machete" su chi non ha provveduto all'iscrizione.

Un ringraziamento a tutti quelli che mi stanno aiutando a spargere la voce e a raccogliere le adesioni. E anche all'ugidotnet che molto sportivamente sopporta questi post forse un po' ingombranti ma che di certo non minacciano la sua importanza.

L'agenda dell'incontro è disponibile al seguente indirizzo: http://www.xedotnet.org/subscriptions.aspx

Il nuovo modello di accesso ai dati basato sui DataSourceControl consente con facilità di fare il binding di controlli complessi come al GridView, la DetailView e la FormView con una facilità impensabile. I controlli DataSourceControl hanno un design fortemente configurabile per adattarsi alle varie esigenze. Ad esempio è possibile con facilità parametrizzare il risultato della DataSource per mezzo di Parametri che possono essere passati come argomenti ai metodi Select, Insert, Update e Delete. I parametri vengono poi tradotti in modo conforme al tipo di DataSourceControl. Ad esempio nel caso della ObjectDataSource essi divengono parametri del metodo richiamato durante una operazione di accesso ai dati.

Esistono un buon numero di questi parametri, ad esempio Parameter, QueryStringParameter, SessionParameter, che hanno il compito di prelevare l'informazione da qualunque supporto sia necessario interfacciare. La struttura di questi parametri è molto semplice tanto che è possibile con semplicità crearne di personalizzati. Ecco ad esempio un tipo di parametro che legge il contenuto di Context.Items e lo passa alla DataSource:

public class ContextItemParameter : Parameter
{
    private string itemName;

    protected override object Evaluate(
        System.Web.HttpContext context, 
        System.Web.UI.Control control)
    {
        if ((context != null) && (context.Items != null))
            return context.Items[this.itemName];

        return null;
    }

    public string ItemName
    {
        get { return itemName; }
        set { itemName = value; }
    }
}

powered by IMHO 1.3

I Web User Controls, più spesso conosciuti con il diminutivo di "ascx" per l'estensione che contraddistingue il loro template, sono sovente sottovalutati per la loro intrinseca facilità di uso. Questo è un grave errore in cui si incorre nell'errata supposizione che la loro semplicità sia ottenuta sacrificando la l'estensibilità tipica dei Custom Web Controls. COn questo breve esempio vorrei dimostrarvi quanto sto dicendo; Poniamo di creare un semplice UserControl come segue:

Come evidente si tratta di uno UserControl che contiene una semplice tabella con nove celle, distribuite su tre colonne per tre righe. Ora andiamo a modificare la classe che implementa la logica dello UserControl:

using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using System.ComponentModel;

public partial class TemplatedUserControl : System.Web.UI.UserControl
{
    private ITemplate buttonTemplate;

    protected override void OnInit(EventArgs e)
    {
        int i = 0;
        foreach (TableRow row in tblTris.Rows)
        {
            foreach (TableCell cell in row.Cells)
            {
                ButtonTemplateContainer container = new ButtonTemplateContainer();

                ButtonTemplate.InstantiateIn(container);
                WebControl textControl = container.FindControl("TitleText") as WebControl;
                cell.Controls.Add(container);

                if (textControl != null)
                {
                    textControl.Width = textControl.Height = Unit.Pixel(50);

                    if (textControl is ITextControl)
                        ((ITextControl)textControl).Text = i.ToString();
                    else if (textControl is IButtonControl)
                        ((IButtonControl)textControl).Text = i.ToString();
                }

                i++;
            }
        }

        base.OnInit(e);
    }

    [PersistenceMode(PersistenceMode.InnerProperty)]
    [Browsable(false)]
    [TemplateContainer(typeof(ButtonTemplateContainer))]
    public ITemplate ButtonTemplate
    {
        get { return buttonTemplate;  }
        set { buttonTemplate = value; }
    }
}

public class ButtonTemplateContainer : 
    Control, 
    INamingContainer
{
}

Questo codice, trasforma lo UserControl appena creato in un semplice ed efficace TemplateControl. In pratica nelle nove celle viene iniettato il template generato sulla base di quanto richiesto nel markup. Ecco come è possibile usare lo UserControl:

<Elite:TemplatedUserControl runat="server" ID="ucTest">
    <ButtonTemplate>
        <asp:Button runat="server" ID="TitleText" />
    </ButtonTemplate>
</Elite:TemplatedUserControl>

In breve sarà possibile configurare un template in ogni istanza configurata dello UserControl allo stesso modo di quello che si farebbe con una GridView. Come evidente le potenzialità degli UserControls vanno ben aldilà di quallo che si può di primo acchito pensare.

powered by IMHO 1.3

Vi segnalo un post del sempre eccellente Matteo G.P. Flora. Si parla di moderne forme di censura, dello stampo di quelle che si pensava fossero ormai riportate solo nei libri di storia. Capiamoci, la libertà fa paura, e Internet è libertà applicata. Quindi...

Da lunedì sono aperte le iscrizioni al primo meeting di XEDOTNET, lo user group che stiamo creando nel triveneto. L'agenda vede la partecipazione di nomi importanti. Lorenzo Barbieri ci intratterrà parlando di Visual Studio Team System e Team Foundation Server, mentre Davide Vernole presenterà in anteprima il Microsoft Expression Designer aka "sparkle".

Nel frattempo sono aperte le votazioni per il logo della community, cui chiunque può partecipare semplicemente postando un messaggio nell'apposito forum che potete trovare qui: http://www.xedotnet.org/forums/thread/24.aspx

Un grazie a Davide Vernole che stamane mi ha segnalato questa novità...

L'accesso alla ViewState nell pagine ASP.NET, ma anche a Session, Cache ed Application tipicamente soffre della mancanza di type-safety che costringe a scrivere dei cast ripetuti. Con il breve e semplice metodo generico qui riportato è possibile semplificare la gestione di questi utili strumenti

public string MyValue
{
    get { return GetViewState<string>("MyValue", string.Empty); }
    set { SetViewState<string>("MyValue", value); }
}

private T GetViewState<T>(string name, T defaultValue)
{
    if (ViewState[name] == null)
        SetViewState<T>(name, defaultValue);

    return (T)ViewState[name];
}

private void SetViewState<T>(string name, T value)
{
    ViewState[name] = value;
}

Leggo con piacere un eccellente articolo di Matteo G.P. Flora che spiega le problematiche relative l'anonimato in rete e soprattutto come proteggere le proprie comunicazioni. Da liberale, trovo che l'anonimato non sia una soluzione auspicabile, perchè tende a proteggere anche chi ne approfitta. Tuttavia è vero che in un periodo in cui la repressione della libertà di espressione si fa sentire, il bisogno di anonimato esiste per tutelare prima di tutto la propria privacy piuttosto che i propri interessi. Ricordo infatti che è abitudine comune quella di tracciare le comunicazioni per scopi che vanno dalla semplice opportunità commerciale (ad esempio i log file dei web server servono a questo), fino alla repressione vera e propria della libertà dell'individuo.

Ecco quindi che l'articolo di Matteo, che parla di Tor, un interessante strumento gratuito per la propria privacy è di notevole interesse. Chissa che Matteo prossimamente non trovi anche l'occasione per parlare di Cypherpunk, Mixmaster e Mixminion e di tutti i software correlati a questi remailer anonimi che consentono di proteggere le proprie comunicazione via e-mail.

Nel Framework 2.0 sono presenti una serie di controlli che sono in gradi di sfruttare un nuovo tipo di binding ai dati. Mi riferisco ai controlli gerarchici, come ad esempio il TreeView, il quale ricevendo una datasouce che implementi una determinata interfaccia è in grado di visualizzare dati che non siano delle semplici tabelle. L'implementazione della datasource gerarchica, richiede la realizzazione di una serie di classi a supporto che a loro volta si basano su interfacce e classi astratte.

Quest'oggi, nel districarmi in mezzo ad esse ho scoperto mio malgrado che quello che si trova in MSDN non è tutto oro colato. Per farla breve, dopo aver replicato esattamente un esempio della documentazione ed aver cercato per ore di capire dove stavo sbagliando mi sono deciso a compilare il codice dell'esempio per poi rendermi conto che esso sofriva dello stesso problema che stavo riscontrando nel mio. Niente meno che una StackOverflowException causata da una ricorsione infinita.

Mi chiedo quanti altri di questi esempi non testati esistano su MSDN.