Segnalo per chi non lo conoscesse un articolo sulla libreria Rewrite.NET di remapping dell'URL per applicazioni ASP.NET, pubblicato su 15seconds.com. E' la stessa utilizzata anche da Rainbow. Il componente consente di slegare l'URL delle proprie pagine da quello effettivo residente sul server. Rewrite.NET è implementato come un HttpModule che agisce sulla pipeline di ASP.NET catturando le richieste http e riscrivendo nell'HttpContext corrente la pagina .aspx corretta da mandare in esecuzione.
Le regole di rewrite possono essere fissate a piacere in quanto sono affidate a un motore pluggabile basato su interfaccia. Se vi servono criteri vostri e di qualunque tipo (che ne so... basati su un database ad esempio) vi è sufficiente creare una classe che implementi l'unico metodo dell'interfaccia RulesEngine.IRules: il metodo Execute. Metodo che riceve l'HttpApplication, il path virtuale richiesto e le configurazioni correnti e deve ritornare il path virtuale rimappato.
Una volta creato il nuovo rewriter vi basta aggiungere una voce al web.config per segnalare il componente alla pipeline e, facoltativamente, configurare eventuali parametri che saranno passati al metodo Execute al momento del rewriting.
Fede_
---
http://www.federicodalmaso.it
ASP.NET PopUp gestisce dei controlli pop-up ad apparizione dal basso simili alle finestrelle di notifica del desktop di Windows. Lo trovate su codeproject, il download dei sorgenti richiede l'iscrizione (gratuita) a codeproject. Disponibile anche un esempio on-line. Molto bello, supporta anche Mozilla e Opera.
SkwMenu invece è un controllo open per la generazione di menu a tendina. Disponibile anche un articolo su MSDN. Autore del controllo e dell'articolo è Scott Mitchell, boss di 4guysfromrolla: una garanzia!
Fede_
---
http://www.federicodalmaso.it
Ho seguito l'ultimissima presentazione su Indigo a cura di Steve Swartz Product Architect di Indigo.
Lo speaker ha mostrato i vari aspetti dell'architettura Indigo che, come gia' detto, e' un ponte tra il mondo object oriented e quello service-oriented. L'intero (sub)framework consente uno sviluppo veloce di applicazioni che scambino messaggi in modo indipendente dal canale, dalla formattazione messaggio, dal protocollo... da tutto insomma.
L'impressione e' che il lavoraccio sia un opera ciclopica. I concetti fondamentali da acquisire sono veramente molti e gli entry point per poter estendere e affinare il comportamento di Indigo nelle proprie applicazioni sono veramente moltissimi. E' stato mostrato come sia possibile, ad esempio, modificare la definizione di una policy di sicurezza e un meccanismo di buffering dei messaggi, semplicemente creando un attribute da usare in modo declarative sul client o sul server. Oppure alternativamente come farlo con un'interfaccia o con una classe configurata su un file esterno.
Senzadubbio e' la parte di Whidbey che piu' mi attrae e che non vedo l'ora di approfondire.
Parallelamente a questa sessione se ne teneva un'altra sul design di architetture orientate ai servizi che chiaramente mi son perso. Purtroppo il dono dell'ubiquita' ancora non ce l'ho!
Ad una domanda finale, un ragazzo chiedeva come Indigo supportase il servizio di code MSMQ. Swartz ha risposto dicendo che la v1 verra' rilasciata sfruttando MSMQ attraverso System.Messaging e secondo due diversi diversi modelli di programmazione, ma che in futuro stanno pensando di ricostruire un nuovo e piu' potente servizio di queueing.
Questo e' l'ultimo, raggiungo gli altri e fra qualche ora svolazzeremo verso l'Italia..... capirete la voglia. :(
Segnalo un
articolo introduttivo su Indigo di Don Box e un
articolo introduttivo sugli Adapters dei nuovi server control di Vandana Datye
Interessantissima la presentazione di Anders Heiljsberg, papa' di Delphi e C# sulle nuove estensioni di C#. Molti ne avranno gia' parlato e si trova molta documentazione sulla rete per cui non mi voglio dilungare. Devo dire che mi ha fortemente entusiasmato il supporto ai generics, che mi ha meravigliato la presenta della parola chiave yield.
La parola chiave yield (da quanto ho capito) associata ad un return (yield return)consente ad una funzione di uscire come un normale return, ma di rientrare ad una successiva chiamata all'istruzione successiva allo yield. Tale costrutto consente di costruire le cosidette coroutines. Se applicato agli iteratori consente di implementare il fatidico MoveNext con due righe di codice: un ciclo for sulla collection interna e uno yield return dentro al ciclo. Ad ogni chiamata della funzione viene eseguito uno step del for interno!
Dulcis in fundo segnalo una piccola imprecisione (solo per ragioni di cronaca) di Heiljsberg. Per dimostare la velocita' di una collection tipizzata con generics Heilsberg ha costruito un ciclo for che riempiva una grande collection di test con degli oggetti e ha misurato il tempo impiegato usando una differenza di due DateTime.Now rilevate prima e dopo il ciclo. Ovviamente e' errato perche' un eventuale switch su un'altro processo eseguito dal sistema operativo durante il for, viene conteggiato come tempo di elaborazione del for stesso. Un benchmark corretto dovrebbe misurare i tick del processo!
Ho seguito ben due sessioni di Don Box su Indigo.
Indigo e' il framework che astrae su .NET l'intera visione di progettazione service-oriented. La visione di Don Box (e di MS) e' quella di un futuro in cui la progettazione di applicazioni non sara' centrata su un modello object oriented distribuito ma su un modello service-oriented centrato sullo scambio di messaggi.
La singola applicazione dovra' essere costruita (ovviamente) secondo i canoni OO, ma la struttura globale della rete distribuita dovra' essere fondata su uno scambio continuo di messaggi.
Indigo astrae tutto questo fornendo un framework unico per lo scambio di messaggi. Indipendentemente dal sistema sotterraneo usato, sia esso remoting, MSMQ, web service di nuova generazione, indigo fornira' all'applicazione un servizio di accesso alla messaggistica unico.
Don Box ha presentato i nuovi concetti che stanno alla base di questa visione, mostrando come Indigo, astrae tutto persino i concetti di localizzazione, di transazione, di routing dei messaggi e cosi' via. Ha mostrato alcuni diagrammi UML alla base delle strutture fondamentali che descrivono un servizio di messaggistica.
Tutte le presentazioni sono state molto teoriche e nessuna applicazione e' stata fatta, effettivamente, girare.
Si capisce che i tre anni di lavoro di Don Box, non si possono condensare in un paio d'ore di spiegazioni. L'argomento e' tanto sofisticato quanto potente. Ne vedremo senzadubbio delle belle.
Ieri ho assistito alla conferenza del program manager dei protocolli dei web service.
E' stata presentata la prima applicazione funzionante completa di gestione della sicurezza, trust federato e supporto transazionale interamente su SOAP.
L'applicazione lavorava su una rete reale di server di Microsoft e IBM che si scambiavano solamente messaggi SOAP. Veniva simulato uno scenario di acquisto B2B che comportava controlli sulle scorte di magazzino e cosi' via. La richiesta d'acquisto veniva fatta da un dipendente di una ditta A verso una ditta B. L'utente era autenticato solamente sulla prima. Il presentatore ha avviato uno sniffer dei messaggi SOAP, ha richiesto una transazione e l'intera platea ha potuto assistere ad un 30 secondi buoni di raffiche di chiamate tra i server, in cui i medesimi si scambiavano chiavi di sicurezza, polici di crittazione, innalzavano coordinatori di transazioni, e si scambiavano commit e rollback a raffica. Tutto e solamente con messaggi SOAP. Alla fine una notifica sul messenger segnalava al cliente l'avvenuto ordine.Dimostrazione che entrera' nella storia :)
Il seguito della session era costituito dalla spiegazione dei molteplici protocolli di estensione degli header SOAP che implementeranno tutte le caratteristiche di cui sopra, sui Web Service di nuova generazione. C'e' moltissima carne al fuoco.
Whidbey conterra' un'implementazione su Indigo che wrappera' l'intero processo di comunicazione tra WS secondo i nuovi standard WS-I.
Ho assistito alla presentazione dei nuovi server control. Innovazioni a dir poco eccezionali. Ve le elenco.
Immagini, file .js e qualunque altra risorsa vengono salvati in un file di risorse e richiamate dall'html generato tramite un'unica pagina di entry point: WebResource.axd con parametri in querystring
Implementazione nativa di callback asincroni. Il javascript puo' richiamare la pagina originale in background per farsi passare nuovi dati. La pagina per l'occasione esegue un ciclo di vita diverso. Nell'esempio si mostrava un editor che eseguiva una sorta di controllo ortografico (fatto dal server) durante la digitazione.
Aggiunto un controlstate (oltre al viewstate) che consente di salvare durante i roundtrip una quantita' minima di dati che garantisca un comportamento decente nonostante le disattivazioni del viewstate.
La generazione del HTML e' affidata a degli adapter pluggabili. Terze parti possono aggiungere adapter a qualunque controllo per la generazione dei piu' disparati output (WML, XHTML, XAML)
e molto altro.....
stay tuned :)
E' appena conclusa la conferenza su objectspaces.
ObjectSpaces e' il layer di persistenza di .NET 2 che permette il mapping di oggetti in database relazionali. Per quel che ho potuto vedere nella presentazione e' una copia (incompleta) del potente framework di persistenza opensource Hibernate di java. Stessi pattern, stessa sintassi, stessi problemi.
Approfondiro' una volta installato Whidbey su una mia macchina, ma l'impressione di una "copiatura profonda" e' forte. Sono molto curioso di vedere...
Nota dolente: la versione 1 supportera' solo i database di famiglia SQL Server. Hibernate supporta 15 diversi db. :(