di .NET e di altre amenità

Pur se lo static type checking è un elemento importante nell'utilizzo di Typescript, tanto da essere già una ragione più che valide nella sua adozione, è chiaro che si può fare di più nella semplificazione del codice Javascript e nella sua organizzazione. Nel corso degli anni si sono consolidate alcune pratiche comuni nella stesura di Javascript, per venire incontro alla carenza dei concetti di base dell'object orientation che sono particolarmente labili e limitati. Tra essi si possono annoverare alcune naming convention - ad esempio prependere un underscore ad una variabile la identifica come privata - e dei veri e propri pattern quali le closure. Tutto ciò in effetti è più che altro una notazione stilistica che una vera e propria caratteristica del linguaggio e spesso e volentieri tali pratiche tendono a renderlo di difficile comprensione e manutenzione. Typescript ha tra i suoi costrutti alcuni che hanno proprio lo scopo di semplificare nettamente il codice mascherando la vera e propria complessità che origina dalla sua compilazione.

Interfacce e classi

Nel precedente articolo abbiamo visto che grazie allo structured typing, Typescript è in grado di riconoscere i tipi semplicemente analizzando la corrispondenza delle proprietà. L'esempio seguente riassume in breve la questione:

   1: function getArea(s: { width: number; height: number; }): number

   2: {

   3:     return s.width * s.height / 2;

   4: }

   5:  

   6: var area = getArea({ width: 20, height: 30 });

   7: console.log(area.toString());

E' del tutto chiaro che questo tipo di notazione, pur se tutelata dal compilatore, è eccessivamente prolissa e a lungo andare puà essere oggetto di errori e incomprensioni. Per questa ragione Typescript ammette innanzitutto la creazione di interfacce, che altro non sono che la definizione del contratto di un tipo, cui il valore deve conformarsi. Un concetto più che normale per chi mastica programmazione ad oggetti. Vediamo un esempio:

   1: interface Shape

   2: {

   3:     width: number;

   4:     height: number;

   5: }

   6:  

   7: function calculateArea(s: Shape): number

   8: {

   9:     return s.width * s.height  / 2;

  10: }

  11:  

  12: var area = calculateArea({ width: 20, height: 30 });

  13: console.log(area.toString());

Nelle prime righe dello snippet è visibile la dichiarazione di una interfaccia "Shape". Essa riporta le proprietà "width" e "height" e viene usata come parametro della funzione calculateArea, al posto della precedente notazione estesa. L'argomento passato alla calculateArea è rimasto invariato, ma se provate a modificarne i nomi vi renderete contro che lo structured typing continua a funzionare come prima, validando il parametro contro la definizione dell'intefaccia. Le interfacce ammettono anche metodi e proprietà opzionali (usando il ?). Ecco un esempio:

   1: interface Shape

   2: {

   3:     width: number;

   4:     height: number;

   5:     color?: string;

   6:     getArea(): number;

   7: }

   8:  

   9: function calculateArea(s: Shape): number

  10: {

  11:     return s.getArea();

  12: }

  13:  

  14: var area = calculateArea(

  15:     {

  16:         width: 20,

  17:         height: 30,

  18:         getArea: function() { return this.width * this.height / 2; }

  19:     });

  20:  

  21: console.log(area.toString());

L'esempio in questione estremizza la definizione dell'interfaccia Shape richiedendo una proprietà opzionale "color" (che poi non viene passata più sotto) e un metodo che effettua il calcolo dell'area. In tal modo la funzione calculateArea non deve fare altro che chiamare il metodo getArea dell'interfaccia per ottenere il valore calcolato. Si tratta di un primo passo verso una conversione object oriented dell'esempio. A questo punto potremmo voler implementare l'interfaccia Shape in diverse figure e fornire una diversa formula per il calcolo. Lo possiamo fare grazie alla presenza delle classi. Vediamo come:

   1: interface Shape

   2: {

   3:     width: number;

   4:     height: number;

   5:     getArea(): number;

   6: }

   7:  

   8: class Triangle implements Shape

   9: {

  10:     constructor(

  11:         public width: number,

  12:         public height: number) { }

  13:  

  14:     getArea(): number {

  15:         return this.width * this.height / 2;

  16:     }

  17: }

  18:  

  19: class Square implements Shape

  20: {

  21:     constructor(

  22:         public width: number,

  23:         public height: number) { }

  24:  

  25:     getArea(): number {

  26:         return this.width * this.height;

  27:     }

  28: }

  29:  

  30: function calculateArea(s: Shape): void

  31: {

  32:     var area = s.getArea();

  33:     console.log(area.toString());

  34: }

  35:  

  36: calculateArea(

  37:     new Square(20, 30));

  38: calculateArea(

  39:     new Triangle(20, 30));

Grazie alla keyword "class" è possibile creare delle vere e proprie classi che, a differenza di quello che succede per le interfacce, che spariscono nel codice Javascript, generano una struttura che chi è avvezzo a Javascript riconoscerà sicuramente.

   1: var Triangle = (function () {

   2:     function Triangle(width, height) {

   3:         this.width = width;

   4:         this.height = height;

   5:     }

   6:     Triangle.prototype.getArea = function () {

   7:         return this.width * this.height / 2;

   8:     };

   9:     return Triangle;

  10: })();

Nel precedente snippet abbiamo anche la dimostrazione che una classe può implementare una specifica interfaccia, per mezzo della keyword "implements" e così facendo il compilatore verificherà a tempo di compilazione che la classe supporti i metodi e le proprietà da essa richieste. Siamo a questo punto arrivati ad una programmazione ad oggetti del tutto raffinata, che poco ha a che vedere con la complessità cui si è abituati con Javascript, totalmente mascherata dal compilatore Typescript.

Oltre all'implementazione di interfacce è del tutto possibile estendere classi esistenti. Per fare questo dovremo utilizzare la keywork "extends" al posto di "implements". Vediamo come usare l'ereditarietà per create una classe "Cube" derivando da "Square":

   1: class Cube

   2:     extends Square

   3: {

   4:     constructor(

   5:         width: number,

   6:         height: number,

   7:         public depth: number)

   8:     {

   9:         super(width, height);

  10:     }

  11:  

  12:     getArea(): number

  13:     {

  14:         return (super.getArea() * 2) +

  15:                (this.depth * this.width * 2) +

  16:                (this.depth * this.height * 2);

  17:     }

  18: }

Usare i moduli

Una volta che abbiamo classi e interfacce i benefici che ne derivano sono numerosi, soprattutto in termini di organizzazione logica del codice e di manutenzione. Il passo successivo è di organizzare il codice in moduli - i programmatori C# li conosceranno meglio come "namespace" - per riuscire a creare vere e proprie librerie i cui nomi siano univoci. Anche in questo Typescript ci aiuta; grazie alla keyword "module" infatti sarà possibile creare dei veri e propri namespace:

   1: module Shapes

   2: {

   3:     export class Square implements Shape

   4:     {

   5:         constructor(

   6:             public width: number,

   7:             public height: number) { }

   8:  

   9:         getArea(): number

  10:         {

  11:             return this.width * this.height;

  12:         }

  13:     }

  14: }

Interessante notare che la classe definita nel modulo "Shapes" è stata decorata con "export". Infatti, una volta che abbiamo messo una classe (o qualunque altro costrutto) in un modulo possiamo renderlo visibile o invisibile all'esterno beneficiando di un incapsulamento che in termini di librerie riutilizzabili è prezioso.

Come si è abituati a fare con i namespace in C#, anche in Typescript i moduli possono essere annidati in modo del tutto analogo, creandoli effettivamente l'uno nell'altro:

   1: module Shapes

   2: {

   3:     export class Square implements Shape

   4:     {

   5:         constructor(

   6:             public width: number,

   7:             public height: number) { }

   8:  

   9:         getArea(): number

  10:         {

  11:             return this.width * this.height;

  12:         }

  13:     }

  14:  

  15:     export module ThreeD

  16:     {

  17:         export class Cube extends Square

  18:         {

  19:             // ... omissis

  20:         }

  21:     }

  22: }

Oppure usando una notazione puntata

   1: module Shapes.ThreeD

   2: {

   3:     export class Cube extends Square

   4:     {

   5:         // ... omissis

   6:     }

   7: }

Ciascuna delle due notazioni può essere tranquillamente utilizzata assieme all'altra creando vere e proprie composizioni in cui i moduli si combinano. Una volta che i moduli sono stati creati sarà possibile raggiungere i tipi definiti nei moduli specificando l'intero namespace:

   1: var square: Shapes.Square;

   2: var cube: Shapes.ThreeD.Cube;

Data la notevole lunghezza e ridondanza che i nomi completi di namespace possono raggiungere è del tutto possibile creare degli shortcut che siano in grado di semplificare la scrittura del codice:

   1: import sh = Shapes;

   2: import sh3d = Shapes.ThreeD;

   3:  

   4: var square: sh.Square;

   5: var cube: sh3d.Cube;

Come a casa propria

Sono convinto che i programmatori C#, ma in generale qualunque sviluppatore sia avvezzo all'uso di un linguaggio evoluto basato sui paradigmi della programmazione ad oggetti, leggendo il codice Typescript si senta bene come a casa propria. In effetti se si da uno sguardo veloce al codice generato dal compilatore si comprende come Typescript sia in grado di fornire strumenti che la programmazione Javascript può dare solo a caro prezzo. Per intenderci vediamo un esempio di cosa sia possibile fare:

   1: module Shapes

   2: {

   3:     export interface Shape

   4:     {

   5:         width: number;

   6:         height: number;

   7:         getArea(): number;

   8:     }

   9:  

  10:     export enum ShapeType

  11:     {

  12:         Square,

  13:         Triangle

  14:     }

  15:  

  16:     export class ShapeFactory

  17:     {

  18:         static create(type: ShapeType, width: number, height: number): Shape

  19:         {

  20:             switch (type)

  21:             {

  22:                 case ShapeType.Square:

  23:                     return new Square(width, height);

  24:                 case ShapeType.Triangle:

  25:                     return new Triangle(width, height);

  26:             }

  27:  

  28:             return null;

  29:         }

  30:     }

  31:  

  32:     class Triangle implements Shape

  33:     {

  34:         constructor(

  35:             public width: number,

  36:             public height: number) { }

  37:  

  38:         getArea(): number

  39:         {

  40:             return this.width * this.height / 2;

  41:         }

  42:     }

  43:  

  44:     class Square implements Shape

  45:     {

  46:         constructor(

  47:             public width: number,

  48:             public height: number) { }

  49:  

  50:         getArea(): number

  51:         {

  52:             return this.width * this.height;

  53:         }

  54:     }

  55: }

  56:  

  57: import sh = Shapes;

  58: var sq = sh.ShapeFactory.create(sh.ShapeType.Square, 20, 30);

  59: console.log(sq.getArea());

Mi è stato segnalato che talvolta il debug di typescript sembra non funzionare. ll debugger mostra i breakpoint con il classico pallino bianco anzichè con quello rosso pieno, ad indicare che non è in grado di trovare le informazioni di debug.

Il problema è capitato a me stesso e sono arrivato a comprenderne la ragione, almeno quella relativa la mia problematica. Per fare in modo che il debug funzioni correttamente è necessrio referenziare il file "non minimizzato" nella pagina html. Infatti la mappa generata dal compilatore (il file .map) fa riferimento a questo file. Se invece, come ho fatto io referenziate il file ".min.js" Visual Studio non è in grado di trovare la corrispondenza e il debug non funziona.

A questo punto rimane però il dubbio... dato che non esistono direttive di compilazione che si possano applicare all'HTML, come faccio a referenziare il file ".min.js" al momento del deploy della release?

Se mi guardo indietro mi vedo, numerosi anni fa, seduto sulla panchina del binario 3 della stazione di Venezia Mestre - probabilmente in attesa del treno che mi portava al lavoro - mentre leggo avidamente di un interessante linguaggio che Netscape aveva realizzato e Microsoft aveva introdotto in Internet Explorer 3.0; tale Javascript. La lettura, del tutto tecnica e didascalica ebbe la capacità di svegliare quelle attenzioni per le questioni "Rich Internet" che tutt'oggi mi accompagnano in varie esperienze.

Javascript, infatti, fu allora la risposta alle necessità che fin da subito permearono l'esperienza dello sviluppo di applicazioni web, in cui il gap nella user experience era talmente ampio rispetto quella della classiche applicazioni desktop da risultare indigesto ai più. Poter in qualche modo accedere alla dinamicità della pagina sul client e migliorare l'interazione con l'utente, era una necessità sentita e in qualche modo Javascript, in compagnia di DHTML, apriva un barlume di speranza.

Paradossalmente, oggi a distanza di almeno 17 anni da allora - in termini informatici almeno un paio di ere geologiche - Javascript è assurto al linguaggio per eccellenza, non esclusivamente dedicato allo sviluppo "rich" ma ormai con ampi spazi anche server-side. Dopo essere passati per numerose esperienze, che hanno visto alti e bassi, corsi e ricorsi, parziali abbandoni e ritorni, alla fine l'unico vero linguaggio che può vantare l'aggettivo "cross-platform" è Javascript.

Ma nonostante la longevità, anche nella sua più recente standardizzazione che va sotto il nome di EcmaScript 5.0, Javascript soffre dei problemi tipici dei linguaggi di scripting. In particolare la mancanza di tipi e la sua peculiare visione dell'object-orientation che omette concetti importanti quali l'incapsulamento e l'ereditarietà. A causa di questi problemi, nello sviluppo di applicazioni reali Javascript diventa un linguaggio ostico e, troppo spesso, pericoloso per la sua capacità di digerire qualunque cosa salvo poi scoppiare nel momento peggiore e cioè dopo il rilascio in produzione.

E' questa la ragione per cui molti si stanno orientando ad un nuovo tipo di strumenti, che abbia la capacità di tutelare lo sviluppatore mediante la type-safety e una programmazione object oriented vera, senza però perdere tutti gli indiscutibili vantaggi di Javascript con il cross-platform in testa a tutti. Microsoft in questo campo si sta muovendo rapidamente con la presentazione di un nuovo linguaggio denominato Typescript, giunto oggi alla versione 0.8.2.

Pur trattandosi di una preview e omettendo ancora molti costrutti che uno sviluppatore normalmente si potrebbe aspettare, Typescript è un linguaggio sofisticato che ha la preziosa caratteristica di estendere Javascript, senza però richiedere un "interprete" nuovo nel browser, perchè il risultato della sua compilazione è Javascript. Un sorgente Javascript è a tutti gli effetti un sorgente Typescript perfettamente valido. Un sorgente Typescript genera comunque e sempre un sorgente Javascript valido. La parte del leone la fanno qui il compilatore "tsc.exe" e l'IDE di sviluppo, che anche se non necessariamente deve essere Visual Studio 2012, qualora lo si utiizzi è in grado di portare l'esperienza di sviluppo a livelli del tutto paragonabili a quelli che si hanno con linguaggi di alto livello come C#.

Ma andiamo con ordine: le prime prove con Typescript si possono già fare online nel playground. Il compilatore Typescript infatti è scritto in Typescript - per inciso è anche open source - perciò è in grado di girare perfettamente all'interno del browser e in questa pagina è possibile scrivere, compilare e provare le prime righe di questo linguaggio, vedendone al contempo il risultato in termini di javascript prodotto. In alternative è possibile scaricare i tool per Visual Studio e avere così una esperienza integrata, garantita da alcuni template e da un editor suddiviso in due aree che mostrano assieme sorgente e compilato.

Possiamo quindi sperimentare facilmente, e per farlo proviamo ad immettere il seguente codice nell'editor online oppure se preferite in Visual Studio 2012:

   1: function calculateHypotenuse()

   2: {

   3:    var c1 = 5;

   4:    var c2 = '2';

   5:    var hy = Math.sqrt(c1 * c1 + c2 * c2);

   6:    alert(hy);

   7: }

Ad un occhio attento appare evidente che, purtrattandosi di codice perfettamente legale per Javascript, esso poi genererà un errore di runtime dovuto al fatto che il valore di c2 è impostato come una stringa invece che come un valore numerico, richiesto dalla funzione Math.sqrt(). Inoltre, un po' meno evidente ma anch'esso sorgente di un ulteriore errore, il valore hy ritornato è un numerico e non può essere passato direttamente alla funzione alert() che richiede una stringa. Il codice così com'è incollato nell'editor di Visual Studio ci metterà immediatamente in guardia proprio a causa dei suddetti problemi:

Visual Studio 2012, mediante le sottolineature in rosso evidenzia il problema, pur trattandosi di codice Javascript senza alcun costrutto particolare di Typescript.

Il compilatore Typescript infatti è in grado di inferire il tipo delle variabili dal loro utilizzo e di conseguenza segnala l'anomalia. Ovviamente, nella parte laterale, il codice Javascript non sarà generato ma sarà sostituito da un commento che riporta gli errori riscontrati.

Piuttosto che correggere semplicemente gli errori, lavorando con typescript, però possiamo blindare il codice dichiarandone i tipi.

Qui sotto vediamo il codice modificato e possiamo notare che a questo punto l'errore, visualizzato da Visual Studio, si è spostato nel punto, più opportuno, in cui avviene l'assegnazione. Il tooltip stesso evidenzia la causa dell'errore molto chiaramente. Poco sotto, parzialmente nascosto dal tooltip, viene usato toString() per fornire una stringa ad alert.

La sintassi di Typescript è piuttosto semplice e leggera rispetto a javascript, lasciando per quanto possibile inalterato il codice originario. Il proposito del team è di mantenere per quanto possibile una compatibilità con lo standard Ecmascript 6.0 in corso di definizione, così da mantenere sempre inalterato il paradigma che sostiene che un sorgente Javascript è un Typescript valido. Una volta corretto l'ultimo errore nell'esempio avremo finalmente un output Javascript come segue:

   1: function calculateHypotenuse() 

   2: {

   3:      var c1 = 5;

   4:      var c2 = 2;

   5:      var hy = Math.sqrt(c1 * c1 + c2 * c2);

   6:      alert(hy.toString());

   7: }

Questo esempio banale, è però significativo e dà la misura di come, grazie al supporto di uno strumento di sviluppo quale il compilatore e in parte dell'IDE di Visual Studio 2012 in grado di sfruttarlo opportunamente, saremo in grado di scrivere codice di qualità che tuteli il nostro operato evitando che i normali errori si presentino nei momenti meno opportuni.

Typescript contiene una serie di altre feature molto importanti, come la definizione di interfacce e tipi custom, che lo arricchiscono di una espressività che spesso è limitata dai costrutti molto arzigogolati di Javascript. Spesso tali feature sono del tutto sostitutive e simulano a compile time feature che Javascript non include. E' il caso ad esempio dei metodi e delle proprietà private che, pur non essendo supportate da Javascript in alcun modo, in Typescript trovano applicazione e un eccellente supporto di intellisense in Visual Studio 2012. Il codice compilato naturalmente perderà questa caratteristica ma solo dopo che essa ha perso la sua utilità.

Il webcast di ieri è oramai passato ed è giunto il momento di pubblicare gli esempi di codice. Abbiamo avuto qualche problema tecnico, i partecipanti non erano molti come speravo, ma tutto sommato è andato bene. Un grazie a tutti coloro che hanno partecipato online e che mi hanno posto qualche domanda.

Link: http://blog.boschin.it/download/Silverlight-Scripting.zip

Scrivere codice in Javascript richiede anche il sobbarcarsi l'onere di contenere le dimensioni di quanto si sta scrivendo. Sarebbe fantastico poter scrivere classi su classi, strutturare al meglio l'applicazione, seguire delle prolisse convenzioni di naming, però alla fine quello con cui sempre dobbiamo fare i conti è la banda e la quantità di dati da trasferire che se sottovalutata potrebbe rendere inutilizzabili le nostre applicazioni.

Qualche volta però basta un po' ingegnaarsi per riuscire a risparmiare un po' di codice e ottenere un risultato più che accettabile. A me ad esempio è successo esponendo eventi custom su dei controlli client derivati da Sys.UI.Control. Quando si espone un event capita spesso di dover allegare ad esso una classe Sys.EventArgs per fornire all'handler notifica di dettagli dell'evento. Nauralmente è sempre possibile estendere Sys.EventArgs per fornire delle proprietà aggiuntive e i relativi metodi get e set tuttavia questo comporta usare parecchie righe di codice la cui utilità è piuttosto limitata.

Utilizzando expando però è molto semplice fare un po' di economia. Grazie ad esso possiamo facilmente "attaccare" proprietà, metodi e quant'altro a oggetti già esistenti.

...
var args = new Sys.EventArgs();
args.myCustomData = "dati...";
...

Inutile creare una classe che estenda EventArgs. E' sufficiente appendere ad essa le proprietà che ci servono e risparmieremo un bel po' di bytes.

Ci ho messo un po' a decidere come intitolare questo post, e alla fine ho optato per questo titolo alla Wertmuller perchè mi sembra che il succo del post che sto scrivendo sia proprio questo: imparare ad organizzare per bene il codice di scripting che come ho già detto più volte ha la spiacevole abitudine di infestare le pagine.

L'idea che vorrei presentare mi è venuta lavorando con la Microsoft AJAX Library, e in breve è diventata il mio modo standard di approcciare lo sviluppo in Javascript su pagine HTML perchè mi consente di lavorare con una sorta di codebehind in cui ragruppo tutto il codice di scripting. La base per poter raggiungere questo scopo è una classina che mi sono scritto in -Javascript:

Type.registerNamespace('Elite');

Elite.Page = function()
{
    this.onload$delegate = Function.createDelegate(
        this, 
        function(eventData) 
            { this.load(); });
      
    this.onunload$delegate = Function.createDelegate(
        this, 
        function(eventData) 
           { this.unload(); });

        window.onload = this.onload$delegate;
        window.onunload = this.onunload$delegate;

        Elite.Page.initializeBase(this, [window]);
}

Elite.Page.prototype =
{
      initialize : function()
      {
          Elite.Page.callBaseMethod(this, 'initialize');
      },
      load : function()
      { },
      unload : function()
      { },
      dispose : function()
      {
           if (this.onload$delegate)   delete this.onload$delegate;
           if (this.onunload$delegate) delete this.onunload$delegate;
        
           Elite.Page.callBaseMethod(this, 'dispose');
       }
    }
}

Elite.Page.registerClass('Elite.Page', Sys.UI.Control);

La classe che ho realizzato dovrà essere utilizzata come base per la classe che rappresenta la pagina. Al suo interno infatti sono stati realizzati una serie di metodi stub che ricalcano il funzionamento normale di una pagina asp.net. Troviamo ad esempio il metodo load() che viene collegato automaticamente all'evento window.onload enaturalmente anche la controparte unload().

Ecco come procedere se si vuole utilizzare questa tecnica in una propria pagina che poniamo si chiami dashboard.aspx:

1) create un file Javascript denominato dashboard.aspx.js. questo consente di tenere i file a scelta in una stessa cartella e reperirli facilmente oppure affiancarli alla pagina e vederli nel solution explorer accanto al codebehind. Al termine dello sviluppo se fate uso del Web Application Project potreste convertire tutti gli script in risorse embedded e caricali con webresource.axd.

2) includere il file javascript contenente la classe Elite.Page (ad esempio page.js). Dato che è obblgatorio fare uso della Microsoft AJAX Library è opportuno mettere la referenza all'interno dello ScriptManager che vi ricordo essere il luogo di elezione per qualsivoglia script.

3) nel file dashboard.asp.js creare una classe che rappresenti la pagina e erediti dalla classe Elite.Page. Ecco un esempio:

Type.registerNamespace('MyApplication');

MyApplication.DashboardPage = function()
{
    MyApplication.DashboardPage.initializeBase(this, [window]);
}
MyApplication.DashboardPage.prototype = 
{
    load : function()
    {
        this.bSave = $get('bSave');
        MyApplication.DashboardPage.callBaseMethod(this, 'load');
    }
};

MyApplication.DashboardPage.registerClass('MyApplication.DashboardPage', Elite.Page);

La particolarità di questa classe è di "registrare" il controllo bSave usando $get(). L'evento load() è il posto migliore per questo genere di attività dato che vi si arriva subito dopo che il download e il rendering della pagina è stato effettuato.

4) Inserire mediante ScritpManager.RegisterStartupScript() il codice che istanzia la classe:

var currentPage = $create(MyApplication.DashboardPage, {}, {}, null, null);

Questa chiamata in particolare istanzierà la classe e inizierà il ciclo di vita invocando il metodo initialize. Poi non appena caricata la pagina sarà invocato il metodo load() e di conseguenza la referenza verrà valorizzata con il controllo bSave. Naturalmente a questo punto sarà opportuno agganciare via script gli eventi dei controlli. Vi ricordo che per fare questo  è necessario l'uso di Function.createDelegate() che come ho già spiegato tempo fa consente di mantenere il contesto di partenza e quindi di rimanere all'interno della classe.

Rimane solo un problema. Sappiamo tutti che i controlli di ASP.NET hanno un id generato a runtime che può essere semplice o composto. Per questo vi sarà necessario passare come argomenti della classe gli id estratti dai ClientID. In realtà ho un'altra idea in incubazione ma... questo sarà l'argomento di uno dei prossimi post.

Giusto ieri ho scritto due righe a proposito di programmazione object-oriented in Javascript e oggi voglio tornare sull'argomento per fare un ulteriore passo verso un lavoro corretto e produttivo. Noi tutti quando scriviamo in C# o in un qualunque linguaggio realmente object oriented siamo abituati a gestire eventi asincroni nel contesto stesso in cui questi sono generati in modo tale che la loro invocazione e la loro gestione rimanga confinata all'interno di una sola istanza di una classe. In Javascript invece, questo non è immediatamente possibile; Spesso e volentieri ci si trova a dover gestire chiamate asincrone, o eventi generati dall'interfaccia e utilizzando un paradigma object oriented ci si trova a gestire eventi fuori del contesto dal quale essi sono generati. Mi rendo conto che spiegare a parole questo problema è difficile perciò vi propongo un esempio che chiarisca. Poniamo ad esempio di voler scrivere una classe che sia in grado di trasformare un elemento dell'interfaccia in un pulsante. Ad essa sarà passato in ingresso un elemento del DOM ed essa sarà in grado di agganciare l'evento onclick e gestirlo quando necessario:

   1: // HTML

   2:  

   3: <div id="myButton">Click Me!!!</div>

   4:  

   5: // Classe Javascript

   6:  

   7: ClickButton = function(message, element)

   8: {

   9:     this._message = message;

  10:     element.onclick = this._onclick;

  11: }

  12: ClickButton.prototype = 

  13: {

  14:     _onclick : function()

  15:     {

  16:         alert(this._message);

  17:     }   

  18: }

  19:  

  20: // USO

  21:  

  22: var bt = new ClickButton("Ciao!!!", $get("myButton"));

Guardando questo pezzetto di codice può sembrare tutto in perfetto ordine ma in realtà se provate a farlo girare in un qualsiasi browser il risultato sarà una message box con scritto "undefined" anzichè come ci si aspetterebbe un caloroso "Ciao!!!". Come dicevo pocanzi il problema è che Javascript non ha la nozione di contesto di una istanza, pur se noi passiamo ad essa un riferimento al metodo _onclick() in realtà stiamo semplicemente copiando in una variabile il corpo della funzione stessa che sarà completamente slegata dal contesto dell'istanza in cui si trova. Per ovviare a questo problema occorre passare all'evento non solo la funzione _onclick() ma anche un riferimento a "this" così che il runtime sia in grado di eseguirla correttamente. Per fare questo nella Microsoft AJAX Library esiste un metodo della classe statica "Function" che serve proprio a generare correttamente questa chiamata. Ecco come modificare la classe di cui sopra per farla funzionare:

   1: ClickButton = function(message, element)

   2: {

   3:     this._message = message;

   4:     element.onclick = Function.createDelegate(this, this._onclick);

   5: }

   6: ClickButton.prototype = 

   7: {

   8:     _onclick : function()

   9:     {

  10:         alert(this._message);

  11:     }   

  12: }

Con createDelegate() verrà generata una funzione che ha appunto lacapacità di invocare il metodo richiesto nel contesto della classe di appartenenza. La definizione del metodo createDelegate() pur con questo nome un po' altisonante altro non è che uno stratagemma per memorizzare il riferimento a this:

   1: Function.createDelegate = function(instance, method)

   2: {

   3:     return function()

   4:     {

   5:         return method.apply(instance, arguments);

   6:     }

   7: }

Chi ha provato ad usare Silverlight si sarà già imbattuto in qualcosa di analogo. In vari siti nella rete si trova la definizione di un metodo Sys.Silverlight.createDelegate() che è del tutto analogo a Function.createDelegate(). Ecco quindi un buon motivo per referenziare la Microsoft AJAX Library anche quando si lavora con Silverlight. Attenzione però che esiste almeno un evento che in Silverlight non potrete gestire con questo metodo. Si tratta dell'evento onResize dell'oggetto Host che tipicamente viene usato per riposizionare il layout al resize del controllo host.

Javascript è un linguaggio ad oggetti, anche se per la massima parte l'uso che se ne fa è quello di scrivere piccole e semplici funzioni con un paradigma procedurale. In effetti scrivere ad oggetti per mezzo di javascript è molto diverso dallo scrivere in un comune linguaggio object-oriented. Molti dei principi di questo tioo di programmazione trovano applicazione solo per mezzo di stratagemmi, come ad esempio nel caso dell'ereditarietà.

La nuova libreria Microsoft AJAX Library, introduce una serie di utility che semplificano questo lavoro e consentono un uso più produttivo del paradigma object-oriented anche in ambito scripting. Per creare una classe in Javascript si può procedere in svariati modi, tuttavia facendo uso della libreria AJAX il metodo consigliato è quello dell'uso del prototype pattern come segue:

   1: MyClass = function()

   2: {

   3:     // costruttore della classe

   4: }

   5:  

   6: MyClass.prototype =

   7: {

   8:     // corpo della classe

   9: }

Le poche righe qui riportate mostrano lo scheletro di classe che si può realizzare facilmente anche senza l'uso della Microsoft AJAX Library. Possiamo facilmente aggiungere un metodo facendo uso della sintassi propria di JSON. Proviamo ad esempio a verificare che esista un effettivo incapsulamento delle informazioni dichiarando un campo "privato" e un metodo che dimostra il valore ad esso assegnato:

   1: MyClass = function(message)

   2: {

   3:     this._message = message;

   4: }

   5:  

   6: MyClass.prototype =

   7: {

   8:     display : function()

   9:     {

  10:         alert(this._message);

  11:     }

  12: }

  13:  

  14: // USO : --------------

  15:  

  16: var msg = new MyClass("Hallo World!");

  17: msg.display();

Il piccolo esempio riportato oltre a dimostrare le potenzialità di questa tecnica, ne dimostra anche i limiti. Ad esempio è piuttosto evidente che il campo "_message" che pur nella nostra immaginazione è evidentemente un campo privato, è facilmente accessibile dall'esterno. Non vi è naturalmente alcun modo di impedirlo, semplicemente perchè in javascript non esistono i modificatori di accesso, ma per convenzione nella libreria Microsoft l'uso di un trattino di sottolineatura sottintende che esso non debba mai essere usato esternamente.

Un'altro rilievo da notare è che l'uso della keyword "this" è obbligatorio. La sua omissione induce l'interprete a cercare una variabile globale con lo stesso nome e tutti noi sappiamo che in programmazione object-oriented di variabili globali non ve n'è traccia alcuna. Infine è da tenere in considerazione che la classe non può specificare una base e che di conseguenza non esiste override.

L'adozione della Microsoft AJAX Library ci da una serie di strumenti che ci permettono di simulare facilmente alcune delle "feature" della programmazione ad oggetti. Tanto per cominciare potremmo organizzare le nostre classi in namespace, dando ad esse una migliore leggibilità:

   1: Type.registerNamespace('Elite');

   2:  

   3: Elite.ButtonBehavior = function(element)

   4: {

   5:     this._element = element;

   6: }

   7:  

   8: Elite.ButtonBehavior.prototype = 

   9: {

  10:     ...

  11: }

La classe "Type" consente di creare un namespace fittizio che poi in seguito dovremmo riportare diligentemente in tutte le ricorrenze del nome. A questo punto ci dovremmo chiedere come fare ad estendere una nostra classe. Facciamo l'ipotesi di aver creato una classe che contenga delle funzioni base per il trattamento di elementi di interfaccia. Tale classe si chiamerà Elite.BaseElement. Mediante i metodi statici alle classi potremmo registrare la nuova classe creata ed assegnare ad essa una base:

   1: Elite.ButtonBehavior.registerClass('Elite.ButtonBehavior', Elite.BaseElement)

Per poter dire di aver completato la nostra classe non ci resta che adoperarci per fare in modo che avvenga l'invocazione dei metodi base. Non dimentichiamo infatti che si tratta pur sempre di una simulazione e quindi qualcosa da fare c'è, soprattutto per quanto riguarda il costruttore:

   1: Type.registerNamespace('Elite');

   2:  

   3: Elite.ButtonBehavior = function()

   4: {

   5:     Elite.ButtonBehavior.initializeBase(this);

   6: }

   7:  

   8: Elite.ButtonBehavior.prototype = 

   9: {

  10:     initialize : function()

  11:     {        

  12:         Elite.ButtonBehavior.callBaseMethod(this, 'initialize');

  13:     }

  14: }

  15:  

  16: Elite.ButtonBehavior.registerClass('Elite.ButtonBehavior', Elite.BaseElement);

Lo scheletro della classe è pronto. Non resta che aggiungere i metodi necessari ricordando che in Javascript le property non esistono ma possono essere emulate con una coppia di metodi get_ e set_. La Microsoft AJAX Library infatti istituzionalizza anche questo consentendo ad esempio in fase di inizializzazione di assegnare i valori come vere e proprie proprietà.