Master Page ed ereditarietà visuale

Questi progetti mi danno la possibilità di parlare di un'altra interessantissima caratteristica di ASP.NET 2.0, nota come Master Page .

In pratica possiamo definire un template (la Master Page, appunto) da cui tutte le pagine della nostra applicazione potranno ereditare visualmente, sia all'interno di VS.NET Whidbey, sia durante l'esecuzione.

Ovviamente una Master Page ha estensione .master e contiene tutto ciò che bene o male potrebbe tornarci utile. La parte personalizzabile da ogni pagina è contenuta all'interno di un nuovo control, chiamato ContentPlaceholder .

Le pagine che "ereditano" da questa Master Page avranno una nuova proprietà specificata all'interno della direttiva Page:

Le pagine poi dovranno avere necessariamente un control particolare al proprio interno, che servirà per riempire il ContentPlaceHolder della Master Page. La sintassi è questa:

In questo modo ASP.NET saprà dove riempire la Master Page e con cosa farlo. Davvero molto ma molto comodo, se pensiamo agli include di Classic ASP oppure agli user controls di ASP.NET, prestati a questo scopo. Dunque finalmente sarà possibile utilizzare funzionalità avanzate, come Themes e Skins, senza bisogno di scrivere codice. Ovviamente ci torneremo in maniera approfondita quando analizzeremo ognuna di questa caratteristica nel dettaglio.

La directory Code

E' ancora possibile utilizzare il code-behind, anche se non è la modalità di default ed anche se la sintassi è diversa.

Un'altra grossa novità è invece la presenza di una directory di nome code, al cui interno possono essere piazzati i codici sorgenti di tutte le classi che andremo ad utilizzare nel nostro progetto.

Verranno compilati automaticamente e saranno a disposizione per essere utilizzati.

A grande richiesta #1: la pre compilazione

Davvero interessante questa possibilità di pre compilare un sito e distribuirlo come un singolo file, che contiene all'interno tutta la logica che serve per ricreare la nostra applicazione, codice HTML incluso. C'è un tool (per ora solo da riga di comando, ma sarà integrato nell'IDE) per creare una singola DLL da distribuire. Molto ma molto comodo quando non si vuole dare il codice sorgente al nostro cliente, essendo già codice nativo e non IL. E poi è sicuramente la soluzione più performante, visto che il Framework non viene richiamato.

A grande richiesta #2: SqlDependecy

Anche se non è pienamente implementato nell'alpha che ho a disposizione (ma lo è nei bits della PDC), è un'altra tra le richieste più gettonate. Sto parlando di SqlDependecy , ovvero di una nuova classe che gestirà le dipendenze su una tabella di SQL Server. In questo modo fintanto che la base dati non viene aggiornata, rimane quella copia (dell'oggetto o della pagina) in cache.
Funziona ovviamente sia per la classe Cache che per l'OutputCache (ovvero, della pagina o di frammenti di essa). Nient'altro da aggiungere, anche perché si aggiunge come opzioni alle dipendenze già definibili con ASP.NET 1.0.

Per dovere di cronaca

Non c'è spazio a sufficienza per analizzare tutto in dettaglio, ma ci sono altre grosse novità. Tanto per dirne alcune, il crosspage PostBack , ovvero il PostBack fatto su una pagina differente. La comparsa di un control, chiamato Wizard , utile per fare maschere guidate e di un DynamicImage control per gestire immagini al volo (e creare album fotografici).

Completa l'opera il nuovo sistema di deployment , che è talmente flessibile da non sembrare vero. Supporterà FTP, FP extension e chi più ne ha più ne metta.
Si potranno cambiare al volo i file (anche uno) direttamente via FTP. E' arrivato il tempo di mandare in pensione il mio WS_Ftp 5?

Conclusioni

Questo articolo ovviamente ha coperto bene o male l'1% di ciò che Whidbey introduce. In particolare di ADO.NET si è detto veramente poco, ho cercato di soffermarmi più sulle novità "visibili" che su quelle nascoste. Va da sé che Whidbey è legato a Yukon, sia come data di uscita, che come funzionalità. In particolare proprio tramite Whideby sarà possibile definire strutture personalizzate in Yukon. Ci sono persone scettiche su questa feature, ma probabilmente come tutte le cose c'è bisogno di utilizzarle a fondo ed usarle al meglio.

Quanto al resto, ho cercato di dare uno sguardo il più completo ed ampio possibile all'argomento. Non so ancora quando e come sarà distribuita l'alpha al pubblico (se cioè non sarà solo un privilegio di chi è stato alla PDC), di sicuro dovrebbe esserci una beta nella primavera del 2004.

Il dev team punta a ridurre lo sviluppo di codice oltre il 70% rispetto a ciò che siamo stati abiutati a scrivere oggi. In realtà l'esempio dei Data Controls dovrebbe chiarire in che direzione stiamo andando.

Resterà comunque possibile strutturare le proprie applicazioni così come lo facciamo adesso (ovvero, con la logica all'interno di classi separate, secondo un modello 3-tier, a 3 livelli) sfruttando ad un esempio un ObjectDataSource come collante.

E poi sarà garantita la compatibilità al 100% con ASP.NET 1.0 e 1.1 . Meglio di così c'è solo poter usare tutto questo ben di Dio il prima possibile.

Approfondimenti

• La sezione speciale sul sito ASP.NET
• Slides e demo da PDC, per chi non c'è stato
• Whitepaper sul nuovo ASP.NET Whidbey
• Il blog di Daniele Bochicchio

Contenuti dell'articolo

• Pagina 1
  • Un passo indietro
• Pagina 2
  • Dopo l'installazione
  • Le funzionalità web di VS.NET Whideby
  • Intellisense migliorato
• Pagina 3
  • Si parte: accesso ai dati!
• Pagina 4
  • Security, membership e roles
  • Non si vive di solo HTML
  • Gli Starter Kits hanno fatto scuola
• Pagina 5
  • Master Page ed ereditarietà visuale
  • La directory Code
  • A grande richiesta #1: la pre compilazione
  • A grande richiesta #2: SqlDependecy
  • Per dovere di cronaca
  • Conclusioni
  • Approfondimenti