giovedì 19 agosto 2010
Se anche a voi è successo di cominciare un progetto con VS2010, ma arrivati ad un certo punto avete avuto la necessità di “tornare” a VS2008, saprete che è necessario andare a modificare a mano una serie di stringhe sia nei file .sln sia nei file .csproj. Se non lo avete fatto ma lo dovrete fare, un tool sarebbe di grande aiuto…
Sebastiaan Janssen ha creato una coppia di semplici file .bat che fa tutto questo per voi, così da rendere completamente indolore il “ritorno” a VS2008.
Potete trovare il post e lo zip contenente i files qui.
domenica 20 giugno 2010
Many people asked me for a simple tutorial that explain how to create a template for converting a control in Windows Forms to XAML (WF2XAML for friends).
Well, it’s a pretty easy task. First, you must download the binaries of WF(2)XAML here. Then, after unpacking it, create a new C# (or VB.net) Library in Visual Studio. In this tutorial we will name it ACME.Templates, but feel free to name it as you wish.
We will create a new version of the button template, so WF(2)XAML will use this template when it will convert Windows Forms to WPF Windows (or Pages).
Add a reference to System.Windows.Forms.dll and to Ingenium.WF2XAML.dll in your project, so the BaseTemplate Class is visible in your project.
Create a Class, name it ACME.Templates.ButtonTemplate and make it inherit from Ingenium.WF2XAML.Templates.BaseTemplate.
1: namespace ACME.Templates
2: {
3: public class ButtonTemplate : Ingenium.WF2XAML.Templates.BaseTemplate
4: {
5: public override System.Xml.XmlElement RenderToWPF(System.Xml.XmlDocument document)
6: {
7: //Fill with custom conversion code...
8: }
9: }
10: }
Override the method RenderToWPF and you’re done!
Well, you may argue, what I must write inside that method? The method must return an XmlElement, so you are responsible to create it, fill it with properties and attributes and return to the engine (the last passage is pretty automatic; in fact you sould only add the statement return _element;)
The base class BaseTemplate has a property Control of type Control that the engine fills with the converting control. In our case, this.Control will contain the instance of Button control that we are going to convert. So, we can use every property of the control to make aour calculations and/or evaluations to emit WPF code. Let’s see a simple code snippet:
1: using System.Xml;
2: using Ingenium.WF2XAML.Templates;
3:
4: namespace ACME.Templates
5: {
6: public class ButtonTemplate : Ingenium.WF2XAML.Templates.BaseTemplate
7: {
8: public override System.Xml.XmlElement RenderToWPF(System.Xml.XmlDocument document)
9: {
10: //Create Element...
11: XmlElement _rootNode = document.CreateElement("Button");
12:
13: //Examine converting control properties and convert them in new properties
14: _rootNode.SetAttribute("Name", Globals.X_NAMESPACE, Control.Name);
15: _rootNode.SetAttribute("Width", Control.Width.ToString());
16: _rootNode.SetAttribute("Height", Control.Height.ToString());
17: _rootNode.SetAttribute("Canvas.Top", Control.Top.ToString());
18: _rootNode.SetAttribute("Canvas.Left", Control.Left.ToString());
19: _rootNode.SetAttribute("Content", Control.Text);
20:
21: //Add some hard coded properties
22: _rootNode.SetAttribute("FontFamily", "Verdana");
23: _rootNode.SetAttribute("Foreground", "#FFFFFFFF");
24:
25: //Add other transformations or add styles/triggers/animations...
26: return _rootNode;
27: }
28: }
29: }
Ok, now compile the class library and copy the dll ACME.Templates.dll in the same directory where resides files of WF2XAML unzipped early. The last step to use your newly created template is to “register” it in the conversion engine. This is made in the WF2XAML.exe.config file. In detail, we must change the row:
<Template ControlName="System.Windows.Forms.Button" ClassName="Ingenium.WF2XAML.Templates.ButtonTemplate, Ingenium.WF2XAML.Templates"/>
in
<Template ControlName="System.Windows.Forms.Button" ClassName="ACME.Templates.ButtonTemplate, ACME.Templates"/>
If you launch WF2XAML to convert a Windows Forms in WPF, every System.Windows.Forms.Button will be converted using your template. Obviously enough, the same explained technique could be applied to User Controls. Please feel free to contact me to report problems, wish lists, and things you may think useful to enhance the conversion process. Happy converting and templating!
giovedì 27 maggio 2010
La notizia è di ieri: il codice di DotNetNuke è disponibile anche in linguaggio c#. Sarà, ma non comprendo comunque uno sforzo (ed un rischio) di questa entità: sviluppo con DNN da anni (dal 2003) e non mi ha mai disturbato il fatto che fosse scritto in VB, nè quando scrivevo anche io in vb (vecchi tempi) nè quando sono passato a scrivere in C#. Forse le uniche persone che ne trarranno giovamento saranno gli sviluppatori che vogliono mettere mano al codice core dell’applicazione. Comunque, lo stesso risultato si poteva ottenere anche mixando i linguaggi, e soprattutto mantenendo separate la versione base (che ha un suo ciclo di vita indipendente da noi) da una eventuale versione “custom” nella quale abbiamo sviluppato delle estensioni.
Una cosa è certa: molti sviluppatori c# si avvicineranno con maggior fiducia a questa fantastica piattaforma di sviluppo.
martedì 11 maggio 2010
Innanzitutto, permettetemi di ringraziarvi: eravate veramente tanti venerdì sera! Da parte mia, spero di essere riuscito a trasferirvi il “Prism Mood” ovvero la forma mentale che dovrebbe essere impiegata quando si affronta un progetto basato su Prism. Per approfondimenti, vi rinvio alla documentazione ufficiale, ai post del mio blog della scorsa estate e, se lo desiderate, potete contattarmi senza alcun problema.
Ho pubblicato le slides ed il codice del meeting. Li potete trovare qui e qui.
Vi ringrazio ancora per la presenza “massiva” e l’interesse dimostrato nell’argomento. A presto con delle belle novità sempre su Prism!
venerdì 7 maggio 2010
Incredibile… da non perdere!!!
giovedì 6 maggio 2010
Il design di un’applicazione è sempre importante. Nel caso di sviluppo modulare con Prism, diventa ancora più importante e può definire la buona riuscita o il fallimento dell’applicazione stessa.
Vi sono essenzialmente due aspetti di design da tenere in considerazione:
- Separazione delle attività
- Progettazione degli “spazi operativi”
Con separazione delle attività, intendiamo la separazione e l’isolamento di alcune funzionalità all’interno di un modulo, piuttosto che all’interno di un altro, oppure la progettazione di componenti condivisi tra i vari moduli. Per esempio, il servizio di accesso ai dati ad una sorgente dati condivisa tra i vari moduli dovrebbe essere progettato per essere condiviso tra i vari moduli, mentre se un particolare modulo deve accedere a dei dati di un legacy database, probabilmente sarebbe meglio isolare tale funzionalità all’interno del modulo.
La separazione delle attività consiste anche nella separazione delle funzionalità di interazione uomo-macchina, ovvero nella suddivisione delle azioni a disposizione dell’utente. Queste azioni potrebbero essere la pressione di un tasto (Command) lo scorrimento e la selezione di un record (Binding), la modifica di dati di una entità ed il suo salvataggio.
Assieme a tutte queste azioni, dovrebbero essere definiti anche gli eventi pubblicati da ciascuno di questi “micro-programmi”, in modo che possa essere efficientemente implementata una collaborazione tra i micro-programmi stessi.
La progettazione degli “spazi operativi” è altrettanto importante in un’applicazione modulare, e consiste nella definizione di un layout operativo efficace, che consenta una interazione uomo-macchina facile ed intuitiva. Questa progettazione deve essere realizzata con in mente l’usabilità, e la modularità ci può venire in aiuto; pensate infatti ai moduli come una sorta di mattoncini Lego che possano essere assemblati “a piacimento” in modo da ottenere il risultato desiderato.
Nell’incontro di Venerdì 7 Maggio a Mestre presso il Novotel Castellana, con XeDotNet, tratterò questi temi. Se siete interessati allo sviluppo modulare delle applicazioni client con WPF e Silverlight non potete mancare!
mercoledì 5 maggio 2010
Come già detto nel mio precedente post, in Prism sono presenti un tale numero di concetti che ci si può perfino sbizzarrire con un piccolo gioco. Quale caratteristica può considerarsi irrinunciabile, rispetto a tutte le altre?
Per quanto mi riguarda, scelgo senza indugio l’infrastruttura di comunicazione, implementata tramite il pattern EventAggregator. Questa caratteristica, infatti, consente di suddividere il carico di lavoro tra vari moduli, realizzando di fatto una “separation of tasks”. Potremmo quindi combinare assieme diversi moduli, ognuno nato per risolvere una diversa problematica, e l’effetto risultante sarà maggiore della somma delle singole parti.
Se ci pensiamo bene, questo approccio rappresenta effettivamente le relazioni interpersonali che intraprendiamo ogni giorno. Nessuno di noi può saper fare tutto o conoscere tutto e per questo ci si rivolge ad esperti e/o professionisti. Perfino la cosa più semplice, come comprare il pane, viene fatta relazionandosi.
Perchè quindi i nostri programmi dovrebbero saper fare tutto da soli? Ma soprattutto, perchè non dovrebbero potersi avvantaggiare di un nuovo modulo che sa “fare altre cose” comunicandogli cambiamenti, interagendo con esso e lasciandogli il compito di risolvere il compito per il quale è stato pensato?
Pensiamo quindi sempre (se possibile) ad un sviluppo modulare, e nel caso di WPF e Silverlight diamo un’occhiata a Prism. Io ci sarò, Venerdì 7 Maggio a Mestre presso il Novotel Castellana. E voi ci sarete?
martedì 4 maggio 2010
Nel meeting di Venerdì 7 Maggio 2010 a Mestre, presso il Novotel Castellana, parleremo di Prism. Sapete però qual’è il problema? Che Prism è un insieme di concetti, ciascuno dei quali meriterebbe un meeting a sè:
- WPF layout, style e design
- Unity & Dependency Container
- Modularity
- Event Aggregator pattern e la sua implementazione
- Command Delegation
- Presentation Patters (MVC, MVP, MVVM)
- UI Composition
Come fare, quindi? Come far stare tutto in un ora e venti? Come fare a non “spiazzare” chi di Prism non sa assolutamente nulla e vuole capire se l’infrastruttra possa fare al caso suo per lo sviluppo del prossimo Windows Client? Cercherò, come sempre tento di fare, di “spiegare applicando”, ovvero creeremo una applicazione reale con Prism, rendendoci conto del lavoro che è necessario per realizzare un client basato su questa tecnologia.
Una delle cose più interessanti (vi dò un’anticipazione) sarà rappresentata dal riuso di alcuni componenti che i più affezionati “followers” dei miei meeting riconosceranno: andremo infatti ad usare tutta l’infrastruttura per i servizi e l’accesso ai dati creata nel meeting NetTiers & Code Generation di maggio 2009. Vedremo quindi come un anno dopo, senza dover reinventare la ruota, questi componenti possano essere impiegati con profitto in una infrastruttura Prism.
Vi aspetto numerosi…e se qualcuno vuole cominciare a seguire il bianconiglio nella sua tana, gli consiglio di cominciare da qui!
lunedì 3 maggio 2010
Venerdì 7 Maggio 2010 terrò a Mestre un meeting per la community XeDotNet che avrà come argomento Prism 2.1, ovvero la “nuova” versione di Composite Application Block per WPF e Silverlight. Molti, in questo periodo, mi stanno chiedendo “cos’è Prism”? Prism è in effetti un insieme di librerie e best practices per la creazione di applicazioni client modulari, estendibili, testabili, basate su pattern stabili e robusti.
Riporto di seguito delle buone ragioni per essere presenti al meeting di venerdì:
- Tutti noi abbiamo sviluppato, sviluppiamo o svilupperemo un client con WPF o Silverlight;
- Prism racchiude in sè una serie di concetti molto interessanti, che meritano attenzione;
- Se dovete sviluppare un client con WPF, sarebbe meglio conoscere le potenzialità, i pro e i contro di Prism prima di fare una qualunque scelta implementativa;
- Mostrerò come si possibile sviluppare un’applicazione totalmente loosely-coupled;
- Implementerò il presentation pattern MVVM per realizzare i moduli, in modo da poter impiegare Blend per il design dell’applicazione;
- Ci si ritroverà per fare quattro chiacchiere in compagnia…
- Alla fine si andrà a mangiare il galletto (PROBABILMENTE questa è la migliore delle ragioni…:-)
Infine, non ho detto una cosa importante: il mio compagno d’avventura sarà il prode Davide Vernole, che parlerà di strumenti per la testabilità del codice e per la produzione di applicazioni di qualità… quindi: cosa aspettate ad iscrivervi? :-)
venerdì 23 aprile 2010
Visto che lo studio delle interfacce utente è ormai entrato di prepotenza nel nostro lavoro (dovrebbe esserlo sempre stato…) vi propongo un vecchio ma attualissimo documento che parla delle Inductive User Interfaces. IUI rappresenta un modello di interfaccia che a mio avviso può essere applicato in molti contesti applicativi, anche se non in tutti.
E’ un documento del 2001, ma se troverete il tempo di leggerlo con aperto VS2010, WPF con una navigation application e Blend (con SketchFlow, magari…), capirete quanto attuale ed utile possa essere la sua lettura.
Potete leggerlo qui.