free hit counter
September, 2008 - Pietro Brambati Blog - Site Home - MSDN Blogs

Pietro Brambati Blog

Developer's stories

September, 2008

  • Pietro Brambati Blog

    Uno sguardo a ASP.NET Dynamic Data – parte 2

    • 14 Comments

    Nel primo post di questa serie abbiamo visto come realizzare una prima applicazione con ASP.NET Dynamic Data (DD). Come dicevo i DD sono pensati per scenari di rapida prototipazione, dove con poco realizziamo un sito completo partendo dalla basedati. Ci tengono a ricordare che questa è solo una possibilità in più, non in meno, possiamo naturalmente partire da zero usando WebForms o, quando sarà rilasciato, ASP.NET MVC e in base ai gusti scrivere più o meno codice oppure optare per un modello piuttosto che per l’altro.

    Nonostante siano pensati per scenari RAD, però, i DD danno una buona possibilità di personalizzazione: in questo post vedremo come:

    • Esporre solo alcune tabelle
    • Visualizzare o meno le colonne delle tabelle esposte
    • Personalizzare il comportamento di visualizzazione delle colonne

    Quali tabelle esporre

    Usando l’attributo scaffoldAllTables nel global.asax abbiamo infatti esposto tutte le tabelle del nostro db. Potremmo, invece, operare selettivamente impostando a false tale attributo e andando a abilitare la/le singole tabelle. Per ogni tabella su db, LINQ to SQL, ha creato una classe partial, che possiamo vedere nel codice del file .dbml. Vediamo ora proprio come estendere queste classi, aggiungiamo un nuovo file Order.cs , che definisce una nuova classe parziale con qualche attributo in più, come mostrato nel seguito:

    image

    Il nuovo namespace System.ComponentModel.DataAnnotation consente di usare l’attributo ScaffoldTalble, con cui possiamo rendere o meno visibile la tabella ai DD. Quindi nel nostro caso abbiamo impostato l’attributo scaffoldAllTables in global.asax a false, mentre abbiamo impostato per la classe Order (e anche Product ) l’attributo ScaffoldTable a true. Se lanciamo l’applicazione ora vedremo “scovate” dai DD due tabelle, come in figura:

    image

    Controllare le colonne che vengono esposte

    Se andiamo a vedere le colonne della tabella Orders, cliccando sul link, notiamo che sono presenti tutte le colonne definite nella tabella, nella figura vedete evidenziata anche la colonna shippedDate, che andremo a modificare nel seguito:

    image

    Se per qualche ragione non volessimo visualizzarla, ecco che possiamo operare sempre sulla classe parziale precedentemente definita, aggiungendo un attributo ScaffoldColumn, dal comportamento intuitivo, come mostrato in figura:

    image

    Questa volta abbiamo dovuto scrivere un po’ di codice in più (bene :-)), definire un MetadataType, una classe nella quale poi definiamo un po’ il comportamento relativo alla colonna ShippedDate. Il comportamento, a meno di errori :-), è quello atteso: se lanciamo il sito e andiamo nella tabella Order, non vederemo più  la colonnaShippedDate, l’attributo in questione, infatti, ha detto ai DD di non visualizzarlo più. Ometto l’immagine, potete immaginare …

    Controlliamo il comportamento delle colonne

    Il comportamento in fase di visualizzazione e modifica dei singoli campi della tabella è definito, come abbiamo visto nel primo post, dai template che si trovano nella directory DynamicData\FieldTemplate, dove trovate come viene visualizzato ogni campo di uno specifico tipo: guardate ad esempio il codice di Boolean.ascx e Boolean_Edit.ascx. Ora, se volessi modificare come vengono visualizzati i campi di uno specifico tipo di tutte le tabelle potrei modificare questi template, ma se volessi operare solo sul singolo campo (ShippedDate ad esempio) di una specifica tabella (Orders) potrei (come ho fatto) sfruttare alcuni meccanismi di estendibilità offerti dai DD. Guardate il pezzo di codice qui di seguito:

    image

    In questo caso sto usando l’attributo DisplayFormat per definire il formato di come deve essere visualizzato il campo in questione (la ShippedDate), in questo caso è una data che verrà visualizzata nel formato mostrato in figura. Inoltre grazie all’attributo UIHint sto indicando ai DD di non usare il template di default per il rendering dell’attributo, ma ho creato un nuovo field template che utilizza il controllo Calendar dell’ AJAX Control Toolkit. Non vi mostro il codice che ho usato per la personalizzazione del controllo, che non è molto, lo sto finendo di preparare per la sessione dei Microsoft Days 08. Il risultato visualizzato è il seguente:

    image
    Dove si nota il calendar in fase di editing della colonna ShippedDate.

    Conclusione

    In questo post avete visto come utilizzare alcune tecniche per personalizzare il comportamento di default dei DD, potendo non solo abilitare\disabilitare specifiche tabelle “scovate” dal runtime, ma anche personalizzando il singolo comportamento di un singolo campo di una specifica tabella, aprendo di fatto a molteplici utilizzi. I DD sono, in oltre, già compatibili con ASP.NET AJAX e anche con l’AJAX Control Toolkit, non ultimo potreste anche voler utilizzare controlli di terze parti per specifiche esigenze…. insomma non male, vero?

  • Pietro Brambati Blog

    Uno sguardo a ASP.NET Dynamic Data – parte 1

    • 21 Comments

    Una delle novità presenti nella SP1 di .NET 3.5 sono i Dynamic Data (DD), o meglio ASP.NET Dynamic Data. In estrema sintesi i DD consentono di generare un sito web completo partendo da un modello dei dati. Vi è mai capitato di dover costruire un’applicazione web in poco tempo, niente di eccezionale, solo per poter permettere di fare operazioni di interrogazione e modifica su una sorgente dati?

    Bene, i DD sono pensati proprio per questi scenari: si parte da un modello dei dati costruito con LINQ to SQL o Entity Framework (ma non solo..) e su questo, delle pagine aspx fungono da template generici, essendo in grado di capire quali tabelle sono presenti nel modello dei dati, di capire come sono fatte e di visualizzarle così come renderle modificabili. Esiste quindi un template unico (condiviso da tutte le tabelle) per le operazioni tipiche che su queste potremmo fare (interrogazione, modifica etc).

    Un altro aspetto importante riguarda il motore di routing su cui si basano, che consente di non legare l’url che chiamiamo nel browser per richiedere una specifica pagina a dove la pagina fisica risieda oppure a come questa si chiami. Inoltre è possibile modificare il comportamento del motore di routing tramite delle regole, in un unico punto, senza dover modificare alcunché nelle singole pagine e come queste si richiamino tra di loro.

    Partiamo con un semplice esempio:

    Da Visual Studio 2008 SP1 ( oppure con Visual Web Development Express 2008 SP1) scegliamo uno dei due nuovi template disponibili:

    image

    Scegliamo Dynamic Data Web Application, perché pensiamo di generare il modello dei dati con LINQ to SQL, se volessimo usare Entity Framework dovremmo scegliere Dynamic Data Entities ….

    Date ora un rapido sguardo al progetto generato che contiene la cartella DynamicData, che a sua volta contiene i template che vi dicevo sopra, in particolare guardate la sottocartella PageTemplates che contiene i template usati dai DD. Qui trovate una descrizione delle pagine incluse di default.

    E’ interessante anche il folder FiledTemplate in cui trovate come viene eseguito il rendering di uno specifico tipo, ad esempio il file Boolean.ascx e Boolean_Edit.ascx contengono il codice che viene generato a runtime tutte le volte che si deve generare la parte di pagina che visualizza una colonna del database di tipo boolean e, come avrete capito, il comportamento cambia se siamo in fase di visualizzazione piuttosto che editing del campo. Quindi, in un unico punto, è stato centralizzato il comportamento per la visualizzazione e la modifica dei singoli campi delle tabelle del database. Posso modificare il codice qui e vedere le modifiche apportate ogni volta che viene visualizzata una colonna che fa riferimento ad un campo boolean su db, di una qualsiasi pagina che venga renderizzata. I DD hanno anche un meccanismo che consente di fare un po’ il contrario: di specificare cioè che un particolare campo boolean, di una particolare tabella sia visualizzato in modo completamente diverso che dagli altri. Vedremo meglio questo meccanismo di estendibilità in un altro post.

    Per ora procediamo oltre e aggiungiamo un modello dei dati basato su LINQ to SQL. Dal menù: Add new Item, quindi scegliamo Linq to SQL Classes, “agganciamo” il nostro database Northwind, o quello che preferite, e senza preoccuparcene troppo facciamo drag & drop di tutte le tabelle, alla fine ci troviamo più o meno nella situazione in figura:

    image

    Nella figura trovate evidenziati il folder DynamicData e il file del modello dei Dati Northwind.dbml.

    Ora andiamo nel file global.asax, semplicemente scommentiamo la riga di codice in cui informiamo i DD del nostro modello, “registrandolo” e aggiungendo il DataContext che mi ha creato il designer, NorthwindDataContext , imponendo a true l’attributo ScaffoldAllTables, che in soldoni dice ai DD di utilizzare tutte le tabelle del mio modello dei dati. E’ doveroso ricordare, come il commento nella stessa pagina global.asax ricorda, questa può non essere la cosa migliore da fare, ma per ora, per il mio esempio, può andare.

    Premendo F5 vediamo la nostra applicazione già bella che fatta. In figura vedete la prima schermata che mostra l’elenco delle tabelle

    image

    Per renderci conto di quanto sia potente il meccanismo di discovery del modello dei dati usato dai DD, premiamo il link che ci porta alla tabella Products, la pagina list.aspx che viene invocata, è un template completamente generico, è in grado di visualizzare correttamente la tabella Products.

    Nella seguente figura, ho evidenziato gli aspetti notevoli che i DD ci mettono a disposizione gratuitamente:

    image

    I DD si accorgono :

    • che la tabella Products ha una relazione di foreign-key con la tabella Category ed invece di mostrarci l’ID della Categoria, ad esempio 1 per il primo prodotto, ci mostra il nome della categoria, cioè Beverages. Potente, no! Lo stesso vale per Supplier.
    • Mettono a disposizione un menù per fare operazione di filtraggio: guardate Discontinued, Category, Supplier: che è generato dinamicamente in base a quali campi boolean e alle relazioni foreign-key presenti nella tabella prodotti.
    • Seguendo i link Edit, Delete e Details si giunge a delle pagine che servono proprio per le operazioni suddette, che ovviamente sono generate a partire dagli altri template, anch’essi generici e adattabili a qualsiasi tabella.

    Il tutto finora semplicemente scrivendo una riga di codice nel file global.asax.

    Il Routing

    Se torniamo al file global.asax, noterete come viene generato l’url per navigare l’applicazione web generata:

    image

    L’url viene composto con il nome della tabella e il nome delle action, a cui viene aggiunta l’estensione aspx. Ora cos’è l’action ? Possiamo pensare alle action come alle azioni eseguite sulla pagina dall’utente. Esiste l’enum PageAction che contiene le action usate di default dai DD. Con un esempio si potrebbe dire che se l’utente clicca sul link Edit, per modificare come è fatto un singolo prodotto, la pagina esegue la relativa action PageAction.Edit e il motore di routing invoca la corrispondente pagina, nell’esempio sopra sarà dunque la pagina Edit.aspx, che trovate nel folder dei template in Page templates.

    Per renderci conto di quanto sia flessibile il motore di routing, possiamo provare ad aggiungere due nuove regole. Le regole seguenti valgono solo sulla tabella “Supplier”.

    image

    Attenzione : le regole hanno una precedenza, quindi dobbiamo applicare queste due regole prima di quella presente di default che è più generica. Questa regola agisce quando scegliamo la tabella Supplier (durante la navigazione ). In questo caso sia che l’utente scelga di selezionare la lista di tutti i supplier (PageAction.List), che scelga di selezionare il singolo supplier (PageAction.Details), la pagina che la visualizza sarà la ListDetails.aspx (anche questa è una delle 4 pagine presenti di default nel folder Page Templates). Nella definizione della regola ViewName è il nome della pagina aspx (senza estensione) che deve farne il rendering. Mentre in verde vedete l’url che apparirà nella address bar del browser, che può essere quello che volete, in questo caso ho semplicemente rimosso l’estensione “.aspx” alla fine dell’url.

    Conclusione

    I DD vanno ad arricchire le funzionalità delle WebForms, offrendo un framework per realizzare applicazioni web data-driven. In questo post abbiamo visto brevemente come iniziare ad usarli vedendo i principi di base del loro funzionamento.

    I DD offrono comunque un meccanismo che permette molte forme di personalizzazione, permettono di usare dei template particolari per fare il rendering di campi specifici di una tabella usando ad esempio i controlli dell’ AJAX Control Toolkit o di terze parti ad esempio per selezionare un calendario, oppure uno slider per decidere una quantità numerica. Le pagine degli ASP.NET Dynamic Data sono già pensate per sfruttare i controlli ASP.NET AJAX.

    Altri attributi consentono di impostare delle regole di validazione sul modello dei dati, ad esempio posso impostare tali regole direttamente sulle proprietà delle classi generate da LINQ to SQL, creando delle partial class. Questo meccanismo consente di accentrare le regole di validazione, che poi “fluiscono” nella UI e valgono in qualsiasi pagina web si faccia riferimento a quella specifica classe...

    Spero di avere stuzzicato la vostra curiosità , almeno per chi non ha ancora avuto modo di provare i nuovi ASP.NET Dynamic Data.

    Link utili

    MSDN library ASP.NET Dynamic Data

    www.asp.net/dynamicdata/

  • Pietro Brambati Blog

    2 chiacchiere

    • 3 Comments

    In queste mesi mi rendo conto di aver trascurato un po’ il mio blog, ok ci sono state le ferie, ma in effetti ero solito postare un po’ più spesso; me ne sono accorto anche perché ho ricevuto un insolito numero di mail: molto interessanti, grazie e spero che le risposte siano state utili :-) e di aver risposto a tutti.

    Nelle ultime settimane in DPE, la divisione Microsoft per cui lavoro, siamo stati un po’ presi, complice il cambiamento del modo di lavorare, persone etc, insomma le solite cose che vi potete aspettare. Inoltre e soprattutto, stiamo lavorando agli eventi MSDN e TechNet dei prossimi mesi. Giusto per darvi qualche anticipazione ci sarà (ok queste informazioni sono completamente non-ufficiali :)) un Roadshow MSDN e TechNet in diverse città italiane tra Ottobre e Novembre dove si parlerà delle ultime novità: in particolare di .NET 3.5 SP1 e SQL Server 2008 e il tutto insieme a molte Community italiane! E’ anche già live il portale dei TechDays – WPC 2008, evento di approfondimento tecnologico che si svolgerà invece il 2-3-4 Dicembre. Quindi preparatevi: tenete monitorati i nostri blog, pronti a fissare le date in agenda. Ora che mi ricordo, ho anche registrato un webcast introduttivo (e sintetico) sulle novità della SP1, ma non è ancora disponibile per il download, quindi ci sarà da aspettare ancora un po’. Mauro mi sta anche conivolgendo in qualche attività con le università, ma per ora niente di certo.

    Ma non è tutto qui, almeno per me :-) Sono alle prese con un cambio casa: potete solo immaginare quanti grattacapi; mi rincuora che in DPE non sono l’unico. Bene mi rendo conto che questo post è (quasi) completamente inutile … ma ormai l’ho scritto.

  • Pietro Brambati Blog

    Supporto nativo JSON in Internet Explorer 8

    • 1 Comments

    Uno dei post che ho letto con più interesse sul blog del team di prodotto riguarda il supporto nativo a JSON di IE 8. JSON è un formato noto a chi sviluppa applicazioni AJAX, ma non solo … direi. In IE 8 sono state aggiunte una serie di nuove API native che consentono di aumentare le performance in fase di serializzazione e deserializzazione ed inoltre verificano il contenuto da deserializzare per “sanitizzare” da codice malevolo.

    Le nuove API mantengono il supporto a JSON come descritto in ES3.1 Proposal Working Draft. Il motore è nuovo e non si basa sulla classica eval().

    Quello che come sviluppatori web abbiamo a disposizione è un nuovo oggetto JSON con delle nuove API, ad esempio JSON.parse e JSON.stringify: la prima fa il parsing di una stringa che dovrebbe contenere dati in formato JSON e ne restituisce il corrispondente oggetto o array, mentre la seconda, fa un po’ l’inverso. L’elenco delle API con tutti i dettagli del caso la trovate al post che vi suggerivo di leggere.

    Nel post trovate anche discusso il comportamento delle pagine che usano note librerie per la gestione del JSON come json2.js; la maggior parte di queste pagine trarrà vantaggio, senza modifica, di queste nuove API girando in modo più veloce, perché sfrutteranno il supporto nativo di IE 8. Per le pagine che hanno implementato una versione custom di un oggetto JSON sono discusse invece due possibile alternative da seguire.

    Ok, non ho resistito a scrivere due righe di codice e farne il debug con i nuovi Dev tools inclusi in IE8. Sulla destra vedete i campi dell’oggetto JSON, risultato del parsing della stringa.

    clip_image002

    Attenzione:il valore del campo Age in figura è puramente indicativo e non attinente alla realtà … forse.

Page 1 of 1 (4 items)