UI Composition
Non si può. Il motivo è abbastanza semplice, esiste uno ed un solo “Region Service”, per ciclo di vita dell’applicazione, che è il main entry point per accedere al mondo delle region, dato un Region Service e una View è possibile ottenere un Region Manager che è colui che gestisce le region per una data View; come minimo quindi esiste un Region Manager per ogni View che ospita delle region. La procedura di registrazione delle region è abbastanza semplice e viene fatta dalla MarkupExtension che lo sviluppatore utilizza nello xaml: <StackPanel rg:RegionService.Region="{rg:PanelRegion Names=”MyRegion”}}" />
...
Questa cosa è rimasta in sospeso da tempo immemore ed è ora di dare un senso, perchè altrimenti un senso non ce l’ha… <semi-cit> :-) La nostra applicazione funziona! ma effettivamente è poco più di un “Hello World”, però funziona. Prometto che diventerà qualcosa di più di un semplicissimo “proof of concept”. Adesso però abbiamo un problema non da poco, ne abbiamo già parlato, e adesso cerchiamo di approfondire e nel limite del possibile dare una soluzione. A volte si dice che un’immagine vale più di mille parole ma in questo caso non è...
Un altro intermezzo, si lo so che ho promesso un’ultima puntata ma: Non ho tempo, ogni tanto lavoro :-); La soluzione che per ora ho adottato per la gestione della navigazione, oggetto dell’ultima puntata, non mi piace, funziona, funziona bene, ma non mi piace… è rumorosa. Facciamo invece un passo indierto: tempo fa abbiamo parlato di “message broker” per sopperire all’impossibilità di usare, in un’applicazione composita, i tradizionali eventi del mondo .net. Una cosa che tipicamente si fa in un’applicazione composita è iniettare contenuti visuali, e lo si...
Mi chiedono: “…Se volessi creare una shell con il ribbon in alto e la possibilità di aggiungere schede al ribbon da parte dei singoli moduli, devo referenziare l'assembly del ribbon da ogni modulo? o c'è un modo più corretto e ordinato per fare le cose? Perchè sarebbe carino se potessi referenziare l'assembly del ribbon da un modulo Infrastruttura e poi da tutti i moduli poter caricare la parte di ribbon dedicata al modulo passando per l'infrastruttura…” Se ho ben capito, e qui liberi di smentirmi, la domanda potrebbe essere generalizzata in: ...
Prima di passare all’argomento centrale di questa lunga trattazione dobbiamo fare un piccolo escursus sul sistema di comunicazione interno all’applicazione. Messaging Il mondo .net ci ha abituato molto bene, gli eventi sono una vera manna dal cielo, ma purtroppo nel nostro caso servono veramente a poco. Facciamo un esempio chiarificatore: Avete 2 oggetti che devono comunicare tra loro, e per l’esattezza, l’oggetto A deve sapere quando succede qualcosa all’oggetto B. Tradizionalmente fareste: Esporre a B un evento; Aggiungere un handler a B.Event da A;...
Scoperto come scoprire quali sono i moduli installati non ci resta che caricarli… fosse semplice ;-) La prima cosa che dobbiamo fare è trovare un sistema per collegare un IModuleDescriptor ad un modulo, dato che le informazioni presenti in un ModuleDescriptor arrivano da un file di configurazione non abbiamo gratis nessun “ponte” tra i 2 mondi: la descrizione di un modulo e il modulo stesso. Quello che possiamo banalmente fare, e che faremo, è aggiungere alcune informazioni al sistema di configurazione, in realtà scopriamo che ci basta aggiungere al file di configurazione un valore che ci dica quale...
La nostra applicazione non fa ancora nulla ma almeno si avvia. Il prossimo passo è quello di realizzare un’infrastruttura per gestire i moduli, in particolare in questa fase ci concentreremo sul processo di discovery. Quali sono i problemi che dobbiamo risolvere: Discovery: il processo di discovery è quello che consente all’IApplicationBootstrapper di capire quali siano i moduli che possono essere caricati, quello che ci dobbiamo limitare a fare è quindi fornire allo strato superiore l’elencodeii moduli disponibili, non è onere nostro fare nessun ragionamento; A questo punto possiamo avere 3 potenziali...
Here we are, lets go deeper! Concentriamo in questo post i primi 2 argomenti: L’organizzazione della solution in Visual Studio, e i problemi che ci dobbiamo portare a casa; La Shell: lo scheletro della nostra infrastruttura; Visual Studio: how to… L’organizzazione della solution in VS è fondamentale per non impazzire durante lo sviluppo e per supportare sia i vostri requisiti sia l’infrastruttura di IoC; quest’ultima è quella che rende particolarmente critica la struttura della solution: Dogma: un framework non deve dipendere da un IoC container; ...
Continuiamo… Siamo ancora ad un livello introduttivo, cerchiamo di capire quali sono le problematiche tecniche che dovremo affrontare e perchè. Dogma: Diamoci delle regole e rispettiamole. Nello sviluppo di applicazioni complesse, e comunque in generale nell’applicazione di un pattern, non abbiamo nessun supporto dall’ambiente di sviluppo, questo significa, ad esempio, che il compilatore (san csc.exe :-D) non ci aiuta in nessun modo segnalandoci che stiamo facendo una certa cosa nel modo sbagliato. Abbiamo quindi bisogno di capire quali sono i problemi, trovare una soluzione che ci permetta di rispettare i requisiti e poi non...
Immaginiamo uno scenario in cui sia necessario soddisfare i seguenti requisiti: Deve essere possibile scomporre l’applicazione in moduli funzionali: I moduli funzionali devono essere independenti l’uno dall’altro; I mdouli funzionali possono avere delle dipendenze logiche tra loro ma l’assenza di una dipendenza non deve precludere il funzionamento dell’applicazione o del modulo stesso; I moduli funzionali devono poter essere rimpiazzati/aggiunti a caldo; ...