Freeteo

Tradurre un report RDLC

Matteo Raumer — Wed, 04 Apr 2012 18:08:58 +0100

Quando si sviluppa un applicativo multilingua, è facile muoversi con le funzionalità offerte dal framework, ad esempio diventa fattibile abbastanza facilmente cambiando la cultura del Thread corrente, e lavorando nel codice con i files di risorse.

Quindi l'approccio è abbastanza standard, e si parte con il creare un file di risorse:

dopodichè al momento della compilazione, Visual Studio genererà per noi la classe che "wrappa" quelle risorse in termini di chiave/valore, e da codice possiamo avere accesso al valore usando le sue proprietà statiche, sia nel codice di markup, sia nel codice vero e proprio, ad esempio:

LogManager.Write(Testi.Disconnessione);

e nel codice di markup:

<TextBlock Text="{x:Static lingue:Testi.Conferma}" Grid.Row="2" />

dove quel "lingue" è un mio namespace che referenzia il mio assembly con le traduzioni):

... xmlns:lingue="clr-namespace: ...

Come dicevamo possiamo cambiare la cultura del thread e il programma per noi si incarica di caricare in quella classe la traduzione nella lingua corretta:

public static void Imposta(string lingua)
{
   //---- safety code
   if (string.IsNullOrEmpty(lingua))
      return;

   string cultura = "it-IT";
   switch (lingua.ToLower())
   {
      case "english":
      case "en-us":
         cultura = "en-US";
         break;
      case "français":
         cultura = "fr-FR";
         break;
      case "portugues":
         cultura = "pt-PT";
         break;
      case "espanol":
         cultura = "es-ES";
         break;
      case "deutsch":
         cultura = "de-DE";
         break;
   }

   try
   {
      CultureInfo cult = new CultureInfo(cultura);
      if (Thread.CurrentThread.CurrentUICulture.Name != cult.Name)
      {
         Thread.CurrentThread.CurrentCulture = cult;
         Thread.CurrentThread.CurrentUICulture = cult;
      }
   }
   catch { }
   }
}

Oltre a questo, ci sarebbe tutto il discorso della Localizable della Form, quindi anche a livello di proprietà dei controlli etc...ma al momento non è importante per questo post.

Quello che volevo invece analizzare in questo post è l'applicazione di queste tecniche ad un Report RDLC, infatti se per l'applicazione è possibile tradurre nativamente tramite il motore del framework, il report non ha qualcosa di già fatto.

Di fatto però il file di report RDLC non è altro che un file XML, quindi è possibile andare a tradurre i valore di alcuni nodi, in base a qualche segnaposto inserito durante il design del report, in questo caso ValueLocID:

E quindi è possibile andare a tradurre il report, andando a cercare appunto quel ValueLocID, nell'esempio "Proprietario" è la chiave, e poi viene tradotta con un codice di questo genere:

public static Stream TranslateReport(string xml)
{
   string ns1 = @http://schemas.microsoft.com/sqlserver/reporting/2008/01/reportdefinition;
   string ns2 = @http://schemas.microsoft.com/SQLServer/reporting/reportdesigner;

   XDocument reportXml = XDocument.Parse(xml);
   foreach (var element in reportXml.Descendants(XName.Get("Value", ns1)))
   {
      XAttribute attribute = element.Attribute(XName.Get("LocID", ns2));

      if (attribute != null)
      {
         string translatedValue = TraduzioniManager.Traduci(attribute.Value);
         element.Value = string.IsNullOrEmpty(translatedValue) ? element.Value : translatedValue;
      }
   }

   Stream ms = new MemoryStream();
   reportXml.Save(ms, SaveOptions.OmitDuplicateNamespaces);
   ms.Position = 0;

   return ms;
}

dove il "Traduci" non fa altro che chiamare il metodo "GetString" del ResourceManager relativo a quella classe "Testi":

static ResourceManager manTesti = new ResourceManager(typeof(Testi));

public static string Traduci(string chiave)
{
return manTesti.GetString("...");
}

In questo modo, è possibile tradurre un report lavorando con l'attributo ValueLocID e un po' di codice del Framework, ma il motore è abbastanza generico anche per report diversi ed eventuali sottoreport.

Sempre al lavoro...anche con Monodroid

Matteo Raumer — Wed, 14 Mar 2012 18:21:41 +0100

E' da un bel po' di tempo che non posto qualcosa sul blog, ed il motivo è presto detto: oberato di lavoro

In particolare negli ultimi mesi sono stato impegnato oltre che come sempre su asp.net /win32 e wpf, su un bel progetto per Android.

Chiaramente sono queste le richieste del mercato, dato che il trend dei device Smartphone e Tablet sono in costante ascesa per la piattaforma Google, inutile aggiungere che Microsoft è in ritardo.

Ma come io sostengo da anni, anche quando si parlava di Java e .net, la mia sensazione è che Microsoft arrivi in ritardo su parecchie cose per vari motivi che non sto qui a spiegare, ma il fatto di arrivare un po' in ritardo spesso le permette di "arrivare meglio".

Per questo stiamo a vedere cosa succede con l'arrivo dell'attesissimo Windows 8, se veramente è quello che mi sembra di aver visto, un ottimo prodotto.

Ma torniamo all'argomento principale del post, il progetto Android.

La richiesta del mercato ultimamente è spesso per questa piattaforma, ed anche io mi sono cimentato al porting di un progetto precedentemente sviluppato in WPF, niente di che a livello grafico, ma cmq fatto con il Framework 4.0 e con una serie di funzionalità che ho cercato di portare in questa piattaforma per device.

Come sempre si vede ingiro cosa è possibile fare, e dato che a quanto pare Silverlight non è supportato da Android ne tantomeno da iOs (quindi iPad ed iPhone) l'unico modo per poter portare il codice, ma soprattutto le conoscenze, rimane Monodroid della Xamarin.

Un ottimo prodotto, dopo averlo usato posso veramente dire che è stato la manna dal cielo, per questa mia situazione.

Monodroid per chi non lo conoscesse ancora, è un pacchetto che si installa e permette di scrivere codice C# (se non erro, dall'ultima versione anche in vb.net) che poi viene compilato ed eseguito su un device Android, quindi tablet o smartphone.

Sempre per chi non li conoscesse ancora, c'è anche il suo "duale" ossia Monotouch, che permette di scrivere C# per iOs.

Ma vediamo qualche dettaglio "operativo", su come ho potuto portare il codice in questa piattaforma,

Partiamo subito chiarendo che il porting "totale" non c'è , soprattutto per le parti grafiche (ad esempio proprio il markup di WPF, gli eventi di binding etc...) ma il codice a livello base è quasi totalmente supportato, Linq e Lambda Expression compresi.

Quindi possiamo partire dall'assunto che lo strato UI è da rifare, e finchè non ci sarà un editor grafico discreto (come quello che ha Eclipse) si va di markup, e test nell'emulatore o nel device fisico. (* per quest'ultima opzione bisogna acquistare la licenza, non basta il demo)

Come dicevo però il codice C# puro è praticamente funzionante totalmente, con tanto di namespace etc...tant'è che non ho fatto un "copia-incolla", mi sono addirittura linkato i file del progetto WPF direttamente nel progetto (una comodità eccezionale):

così facendo i file rimangono esattamente gli stessi, e a meno di avere i namespace corretti, tutto compila e funziona a meraviglia.

* Chiaramente attenzione perchè con il doppio-click si apre il file orginale, quindi se si va a modificare si modificano i file di un altro progetto, attenzione anche nel debug.

Con questa mossa astuta, gran parte dei miei layer applicativi sono stati integrati direttamente nel progetto Monodroid, senza toccare nulla.

* Come si vede dall immagine il tutto [ stato sviluppato dentro a Visual Studio, ma la stessa cosa vale anche se si usa MonoDevelop.

L'applicazione chiaramente ha una tutta la parte di layout delle maschere da riscrivere, e le difficoltà ci sono eccome:

- usare il markup e provare ogni volta per essere sicuri che funzioni, dato che non c'è il designer WYSIWYG:

- l'equivalente di una maschera è l'Activity ed ogni parte di Layout ha biosgno di un bel po' di codice dove si vanno a prendere i controlli del markup e castati nel tipo corrispondente:

Fare a codice tutte queste cose che Visual Studio fa da sempre per noi nel designer, a volte è frustrante...

- gli eventi non sono linkati con il doppio-click dentro al designer

- alcune cose di markup hanno bisogno di impostazioni di layout obbligatorie (a meno di non usare gli style)

- capire come gestisce le Resources Android, soprattutto per le traduzioni

- a volte l'intellisense dentro al Markup non funziona

Sinceramente la fatica si deve fare comunque, anche se avere già di questi vantaggi è sicuramente incoraggiante per lo sviluppo di applicazioni C# in ambienti Android...

e per chi si cimentasse in questi sviluppi, puo' condividere la propria esperienza nel forum di dotnethell...

MVP Award, e sono 4

Matteo Raumer — Mon, 03 Oct 2011 09:39:09 +0100

Eh sì, per me il 1° di Ottobre è sempre una data particolare, una di quelle giornate in cui ti ossessioni a fare invia/ricevi in Windows Mail, in attesa di qualcosa di importante.

Spettacolare, anche quest'anno è arrivata la mail che mi comunicava la nomina di MVP per la categoria C#, e siamo a quota 4, che gioia!!!

Come sempre ringrazio tutti e rinnovo l'invito a vederci sui forum di dotnethell, l'utente Freeteo è presente!

Windows 8, prime impressioni

Matteo Raumer — Mon, 19 Sep 2011 17:09:52 +0100

In questi giorni anche io ho seguito con interesse la //Build per capire quali siano le direzioni future di Microsoft e senza attendere, neanche a dirlo, appena è uscita la Developer Preview l'ho subito installata in Virtualbox sul mio pc per averla sempre a portata di mano e testarla piano piano.

Successivamente l'ho installata anche nel mio Netbook Asus eeepc 1000h (a dispetto di tutti quelli che dicono che i Netbook sono morti, sul questo win8 funziona discretamente, parliamo di un oggetto almeno 3 anni fa...) che uso come "tablet" quando sono a casa, in attesa di uno Slate dal prezzo contenuto (uscirà mai?)

Dopo aver visto le varie Keynote e qualche sessione, ho avuto la netta impressione che Microsoft si stia svegliando: indubbiamente ha accusato il colpo di Apple ed ultimamente di Android che dominano ancora pesantemente nel mercato mobile, e comincia a tremare anche in altri ambiti, perciò urge un "re-thinking" di un po' di cose...

Win8 è anche sinonimo Tablet ma a parte tutto, la vera domanda che interessa a me sviluppatore è:
le mie applicazioni, sia quelle che ho sviluppato io in questi anni, sia quelle che uso, funzionano tutte così come sono adesso? Sì!

Perchè il mio è un punto di vista sviluppatore, ma la cosa che spesso si tende a sottovalutare quando si abbracciano delle "mode" elettroniche, è che non tutto quello che hai funziona nei nuovi sistemi, a partire da tutti quelli che sento correre a comprare IPad o tablet Android, soprattutto in ambito enterprise...

Quindi la primissima cosa che ho fatto è stato installare subito alcune applicazioni che uso in Win7 e vedere se tutto funzionava, queste sono alcune finestre che mi sono trovato davanti nei vari test:

Silverlight si diceva che non era supportato? ho provato qualche sito e tutto funziona alla perfezione (demo dei controlli per Silverlight della Telerik):

Provando un'installazione di un'applicazione distribuita tramite ClickOnce:

Un'applicazione sviluppata con il framework 3.5, alla partenza ha richiesto conferma per fare l'installazione (arrangiandosi) e un'applicazione Vb6 attiva da parecchi anni, con una serie di OCX (librerie custom, runtime di Crystal Report etc...) dopo il setup fatto con InstallShield, sembra funzionare correttamente.

Quindi, a quanto pare le nostre "vecchie" applicazioni funzionano, chiaramente nella modalità "desktop" e non "Metro", ma a me non importa per niente questa cosa, adesso!

Per me questo non ha prezzo, posso veramente pensare di portare il mio desktop sul tablet così come lo conosco...poi facciamoci l'interfaccia Metro, diamo supporto "quasi nativo" a Html5 etc...ovvero tutto quello che si vuole per il prossimo "futuro", ma la cosa importante ADESSO è che le applicazioni funzionino "così come sono" e non sia necessario riscriverle per le diverse piattaforme...

Mi rendo conto che colossi come Microsoft spesso siano lenti, e devo dire che la cosa a volte possa urtare i nervi a noi dev che possiamo saltare tra le tecnologie con velocità...tuttavia non oso immaginare quanti problemi possa avere quando decide di cambiare alcune carte in tavola burocrazia, brevetti, team da coordinare, studi ingegneristici, linguaggi diversi, background da mantenere e chi più ne ha più ne metta...

Ad ogni modo, devo ammettere che sono stato positivamente colpito da quanto ho potuto provare, veloce affidabile e soprattutto retrocompatibile...l'unica cosa che ancora non capisco, è il "silenzio" su Silverlight/WPF se non un accenno di Scott Guthrie durante lo streaming su Channel9 a fine conference, ma forse ci sarà nei prossimi mesi una conference per Silverlight, in cui si parlerà dell'integrazione con Metro?...facile.

Vediamo come evolve il nuovo nato, intanto non posso che apprezzare gli sforzi degli sviluppatori...i presupposti sono buoni, stiamo a vedere cosa ci riserva il futuro...

Entity Framework Code-First: Ereditare da un oggetto base per campi comuni a più tabelle

Matteo Raumer — Mon, 27 Jun 2011 22:32:44 +0100

Entity Framework 4.1 è sicuramente un passo avanti nel pacchetto, ma per quanto mi riguarda Code-First è finalmente qualcosa che si avvicina al mio modo di approcciare l'applicazione.

Mi piace scrivere codice e mi piace non essere troppo legato al database, non tanto perchè mi capiti spesso di cambiarlo (sinceramente quasi mai) più che altro per avere controllo completo su tutti gli strati, in particolare quello delle entità che chiaramente è trasversale a tutti gli altri.

In particolare sebbene mi trovo ad avere già il database nel progetto che sto sviluppando (di cui tral'altro non potevo cambiare più di tanto perchè utilizzato da precedenti applicazioni) ho trovato molto utile partire ugualmente dal codice per modellare "più pulito".

Inoltre fino ad oggi ho sempre sofferto il fatto di non riuscire a far ereditare la maggior parte degli oggetti da un OggettoBase come oggetto e basta, senza dover avere situazioni come Table per Hierarchy (TPH), Table per Type (TPT), Table per Concrete class (TPC) legate cmq al database:

più banalmente, volevo dare a tutte una proprietà "Id" (per me non può esistere nessun oggetto privo di un Id...) e dei campi di sistema "ModificaData", "ModificaUtente" (presenti in tutte le tabelle del database) impostati in un unico punto, e non "copiati" su tutte le varie entità.

Con linq2sql o EF < 4.1 non ero ancora in grado di farlo, ora finalmente posso fare in questo modo:

- Definire un OggettoBase con le proprietà (che specifica già il mapping sui campi):

public class OggettoBase
{
   [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
   [Column("ID")]
   public int ID { get; set; }

   [Column("ModificaData")]
   public DateTime? SYSData { get; set; }

   [Column("ModificaUtente")]
   public string SYSUtente { get; set; }

}

- Definire l'entità che eredita dall'OggettoBase

public class Cliente : OggettoBase
{
public string Nominativo { get; set; }
public string CodiceFiscale { get; set; }
}

- Definire la mappatura della classe che eredita, da notare che non c'è riferimento alla classe OggettoBase, mentre il MapInheritedProperties va messo prima del ToTable(...) di modo che vengano fatte le mappature anche dell'oggetto base:

class ClienteMapping : EntityTypeConfiguration<Cliente>
{
   public ClienteMapping()
   {
      //--- non necessario, vedi update più in basso
      //--- Map(x => x.MapInheritedProperties());

      //--- imposto la tabella relativa all'oggetto
      ToTable("CLIENTI");

      //--- questa proprità ha un campo diverso dal nome della proprieta
      Property(x => x.CodiceFiscale).HasColumnName("CodFisc");

      //--- il resto delle proprietà non serve perchè hanno lo stesso nome
   }
}

* UPDATE: Come segnalato da Tony Pierascenzi la chiamata al metodo "MapInheritedProperties" non è necessaria in questo caso, lo fa direttamente per noi il runtime di Entity Framework.

- Ed infine il nostro DbContext:

public class ApplicazioneContext : DbContext
{
   protected override void OnModelCreating(DbModelBuilder modelBuilder)
   {
      //--- mapping
      modelBuilder.Configurations.Add(new ClienteMapping());

      //--- fine
      base.OnModelCreating(modelBuilder);
   }

   public DbSet<Cliente> Clienti { get; set; }
}

Oltre alla comodità e la pulizia del codice, rimane un obbiettivo raggiunto perchè come è facile intuire, da amante del codice, mi dava proprio fastidio non riuscire a fare una cosa così banale come ereditare da un oggetto base...

In allegato il progetto d'esempio: http://dotnethell.it/users/files/1622_EF.CodeFirst.zip