Uno sguardo a ASP.NET Dynamic Data – parte 2

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:

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:

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:

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:

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:

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:

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?