Data la classe ContactFieldImport così implementata:

   1: public class ContactFieldImport

   2: {

   3:     public string Property { get; internal set; }

   4:     public string Field { get; internal set; }

   5:  

   6:     public ContactFieldImport() { }

   7:  

   8:     public ContactFieldImport(string property, string field)

   9:     {

  10:         Property = property;

  11:         Field = field;

  12:     }

  13: }

vogliamo creare una struttura IEnumerable<ContactFieldImport> popolata con una embedded resource definita nell’assembly locale.

Questa risorsa è un normale file di testo e contiene quanto segue:

FullName;Denominazione|

ManagerName;Titolare|

HomeAddress;Indirizzo|

HomeAddressPostalCode;CAP|

HomeAddressCity;Città|

HomeAddressState;Provincia|

Email1Address;Mail|

Body;Note|

CompanyName;RagioneSocialeFiscale|

BusinessAddress;IndirizzoFiscale|

BusinessAddressPostalCode;CapFiscale|

BusinessAddressCity;CittàFiscale|

BusinessAddressState;ProvinciaFiscale|

GovernmentIDNumber;PartitaIva|

OtherAddressCity;LuogoNascita|

OtherAddressCountry;Cittadinanza|

OrganizationalIDNumber;Matricola|

Ogni riga contiene una coppia Property/Field. Ho usato il pipe ‘|’ come separatore per le linee, e un ‘;’ per separare i due campi.

Possiamo farlo con Linq? Certo, con una piccola funzione come questa:

   1: private static void setupMappings()

   2: {

   3:     string mappingsFile = CoreServices.GetResourceContents("VivendoByte.MyProject.Core.ContactMapping.txt");

   4:     string[] lines = mappingsFile.Split('|');

   5:  

   6:     mappings = from l in lines

   7:                where (l.Length > 0)

   8:                let splitted = l.Split(';')

   9:                    select new ContactFieldImport

  10:                    {

  11:                        Property = splitted[0],

  12:                        Field = splitted[1]

  13:                    };

  14: }

La riga (3) restituisce tramite un metodo statico il contenuto della risorsa illustrata prima. Splitto le righe usando come separatore il carattere pipe ‘|’ (riga 4). Questa operazione di splitting restituisce un array di stringhe che – lo ricordiamo – è un oggetto interrogabile con Linq. Le righe 6-13 compongono una query Linq applicata su un string[]: filtro solamente le righe il cui .Length > 0, poi splitto e metto il risultato in un oggetto splitted. Per ogni riga restituisco un oggetto ContactFieldImport che va a popolare l’oggetto mappings dichiarato come IEnumerable<ContactFieldImport>.

Send to Kindle

In queste sere mi sto divertendo, se così si può dire, con la creazione di un plug-in per Microsoft Outlook 2007. Lo scopo è quello di importare nel folder Contacts di Outlook un’archivio di anagrafica, suddiviso in diverse categorie. Per farla breve vi faccio vedere solo due tabelle che illustrano il contenuto dell’anagrafica di cui sto parlando.

La tabella Tipi contiene la definizione delle categorie. Il campo “Tipo” contiene il nome della categoria (Cantanti, Gruppi, Discoteche, Pub, Feste in Piazza, etc.). Il campo “Lettera” contiene un singolo carattere (C, G, D, P, F, etc.) che indica con quale lettera è identificata una certa categoria; tale campo serve per andare in JOIN sulla tabella Anagrafica. In questo modo ogni record di Anagrafica appartiene ad una ed una sola categoria della tabella Tipi. Le relazioni mostrate nell’immagine qui sopra credo siano abbastanza chiare. Non accetto critiche sul database: l’ho ereditato io 10 anni fa su Access 2.0 e oggi gira in produzione su Access 2003 dopo tutti questi anni. Mi dovrei vergognare per questo? Forse sì, forse no, ma così è e così me lo prendo. 🙂

Comunque, lo scopo è quello di elaborare ogni record di Anagrafica e di creare un’istanza di Microsoft.Office.Interop.Outlook.ContactItem, popolandone tutte le proprietà pubbliche, e poi di salvarlo dentro Outlook 2007. Ecco uno stralcio di C# per dare l’idea:

 1 foreach (MyDataSet.AnagraficaRow row in dataset.Anagrafica.Rows)
 2 {
 3     if (ContactAdding != null) ContactAdding(this, new ContactEventArgs(string.Empty));
 4     Outlook.ContactItem item = ContactServices.CreateContact(row);
 5 
 6     if (item != null)
 7     {
 8         item.Save();
 9         if (ContactAdded != null) ContactAdded(this, new ContactEventArgs(item.FullName));
10     }
11 }

Dato che si tratta di un prototipo mi sono semplificato la vita con un DataSet tipizzato. Ciclo su tutte le righe presenti nella DataTable. Per ogni riga sollevo due eventi ContactAdding e ContactAdded (ContactAdding e ContactAdded sono due public event, ContactEventArgs è una classe derivata da EventArgs). Ma il succo è la chiamata al metodo statico CreateContact, metodo che prende in input un’istanza di AnagraficaRow e restituisce un’istanza di ContactItem.

Tecnicamente parlando, possiamo implementare questo metodo in tanti modi diversi. Io ne ho pensati ed implementati due:

1. assegno una ad una le proprietà pubbliche di ContactItem valorizzandole con i campi esposti da AnagraficaRow
2. uso Reflection per fare qualcosa di più ingegnoso e gestibile nel prossimo futuro

Per il punto (1) il codice dovrebbe essere una cosa simile a questa:

1 ContactItem item = (ContactItem)folder.Items.Add(OlItemType.olContactItem);
2 if (!row.IsDenominazioneNull()) item.FullName = row.Denominazione;
3 if (!row.IsTitolareNull()) item.ManagerName = row.Titolare;
4 ...
5 ...

Alla riga (1) creo un’istanza di ContactItem, poi valorizzo le proprietà FullName, ManagerName e così via, per le decine di campi di cui necessitate (le mie sono 18). Noioso e davvero poco manutenibile.

Il punto 2 è più interessante, perchè tramite Reflection possiamo creare dinamicamente un’istanza di ContactItem. Creiamo una classe ContactFieldImport così implementata:

   1: public class ContactFieldImport

   2: {

   3:     public string Property { get; private set; }

   4:     public string Field { get; private set; }

   5:  

   6:     public ContactFieldImport(string property, string field)

   7:     {

   8:         Property = property;

   9:         Field = field;

  10:     }

  11: }

Ogni istanza di ContactFieldImport rappresenta una coppia di Property/Field. Possiamo così definire una List<ContactFieldImport>:

   1: List<ContactFieldImport> props = new List<ContactFieldImport>();

   2: props.Add(new ContactFieldImport("FullName", "Denominazione"));

   3: props.Add(new ContactFieldImport("ManagerName", "Titolare"));

   4: props.Add(new ContactFieldImport("HomeAddress", "Indirizzo"));

   5: props.Add(new ContactFieldImport("HomeAddressPostalCode", "CAP"));

Ogni coppia definisce come popolare un oggetto ContactItem. Prendo il valore del campo (Field) e con esso valorizzo la proprietà pubblica (Property) di ContactItem. A questo punto il gioco è semplice.

   1: foreach (ContactFieldImport cfi in props)

   2: {

   3:     PropertyInfo pi = typeof(_ContactItem).GetProperty(cfi.Property);

   4:  

   5:     if (pi != null && pi.CanWrite && !string.IsNullOrEmpty(row[cfi.Field].ToString()))

   6:     {

   7:         pi.SetValue(item, row[cfi.Field], null);

   8:     }

   9: }

Itero su tutti gli elementi contenuti nella lista props. Per ciascuno degli elementi, ottengo un riferimento alla PropertyInfo puntata da cfi.Property. Se la PropertyInfo è valida, può essere scritta (CanWrite == true) e se l’AnagraficaRow corrente è una stringa valida, allora imposto la proprietà dell’istanza di ContactItem (riga 7).

Dal punto di vista prestazionale, il ciclo for…each qui sopra è molto più veloce rispetto al primo metodo, quello che cioè che settava le proprietà pubbliche di ContactItem una ad una, senza una sorta di automatismo. Non so darvi con esattezza l’ordine di grandezza, ma ho provato ad importare con tutti e due i metodi qualcosa come 1.400 anagrafiche e tramite Reflection le cose erano molto migliori (< 1 minuto).

Il risultato finale visto in Outlook 2007 è il seguente:

Dentro Contatti ho creato un folder Winshow Planning (nome del progetto), all’interno del quale ho creato tre subfolders (Agenti, Artisti e Luoghi). In ciascuno dei tre ho finalmente creato tanti ulteriori subfolders (presi dal database). Ogni folder contiene i contatti assegnati ad ogni categoria.

‘Sto post è davvero troppo lungo e prolisso. Se avete domande, sono qua a disposizione. 😉

Send to Kindle

1 ContactItem item = (ContactItem)folder.Items.Add(OlItemType.olContactItem);
2 MemberInfo[] mi1 = typeof(ContactItem).GetMembers();
3 MemberInfo[] mi2 = item.GetType().GetMembers();
4 
5 Console.WriteLine(mi1.Length);
6 Console.WriteLine(mi2.Length);
7 
8 // m1.Length = 0
9 // m2.Length = 7

L’istanza item è di tipo ContactItem. Se chiamo GetMembers() sul GetType() di questa istanza ottengo un’array di mi1.Length.

Se chiamo GetMembers() sul typeof(ContactItem) ottengo un’array di mi2.Length.

Il primo array contiene 0 elementi. Il secondo array contiene 7 elementi. Difatti, indagando più a fondo:

// item.GetType() --> {Name = "__ComObject" FullName = "System.__ComObject"}
// typeof(ContactItem) --> {Name = "ContactItem" FullName = "Microsoft.Office.Interop.Outlook.ContactItem"}

Qualcuno sa perchè? Vi è già capitato? Avete percorso la mia stessa strada con risultati diversi?

Send to Kindle

Quando abbiamo imparato a programmare secondo la metodologia OOP, tutti, chi prima e chi dopo, abbiamo imparato che se ad esempio volessimo creare un nuovo controllo conviene ereditare da quello che più gli assomiglia ed implementare solo la parte richiesta. Quindi, se avessimo bisogno di una TextBox specializzata per lavorare con url, potremmo creare una classe UrlTextBox:

public class UrlTextBox : System.Windows.Forms.TextBox
{ }

E ancora, se avessimo bisogno di una Label particolare, mi potremmo creare uno UserControl che erediti da System.Windows.Forms.Label. E così via.

Una cosa di cui sento parlare poco negli ambienti virtuali che frequento è la possibilità di applicare lo stesso tipo di approccio anche con intere applicazioni, a patto che queste ‘intere applicazioni’ siano abbastanza amichevoli – passatemi il termine – per permettere a qualcun’altro di interagire con loro. Spesso noi programmatori abbiamo la tendenza a non pensare neanche ad una soluzione di questo tipo. Vogliamo partire completamente da zero nello sviluppo, più che altro per così sappiamo che avremo il pieno controllo di tutti gli strati applicativi.

Ora, lasciate che vi illustri uno scenario. Supponiamo di dover scrivere un’applicazione che fondamentalmente debba gestire un calendario. L’anagrafica è composta da artisti e locali. Il calendario conterrà appuntamenti, dove si esprime il fatto che un certo artista andrà in un certo locale in un certo periodo della giornata per cantare e ballare ed incassare tot euro. L’appuntamento avrà caratteristiche particolari: il compenso dell’artista, la sua provvisorietà o meno, l’agente, note varie, etc. etc. L’applicazione dovrà fornire all’utente una vista semestrale del calendario, artista per artista e locale per locale. L’applicazione dovrà avere un modulo di fatturazione, molti diversi tipi di report, e molto altro ancora.

Ma l’applicazione di cui sto parlando è fondamentalmente un calendario, al quale vengono applicate determinate restrizioni in alcuni casi. Quindi, mi stavo chiedendo, invece di scrivere tutto da zero, perchè non sfruttare ciò che già c’è. Perchè non partire da un’applicazione esistente, e restringere ciò che va ristretto, ed estendere ciò che va esteso? Perchè non scrivere una cosa del tipo…

public class MyApplication : Outlook
{ }

e lavorarci su con strumenti come Visual Studio Tools for Office ? Non è che si fa proprio così, ma è solo per rendere l’idea. Creare ribbon e toolbar, integrare plug-in capaci di fare tutto il necessario, capaci di incorporare al loro interno componenti realizzati con framework complessi come Windows Presentation Foundation.

Non è che le cose diventino pù semplici, magari fosse così, è solo che viene spostata la nostra attenzione, dal momento che l’applicazione host ci dà già alcuni servizi aggratis.

Meditate gente, meditate.

Send to Kindle