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:

E’ proprio necessario che un modulo sappia che la Shell visualizzerà/utilizzerà un controllo Ribbon per gestire la parte commanding?

La risposta è definitivamente si, ma facciamo un passo indietro… Ho un’applicazione in produzione da qualche hanno basata concettualmente sullo stesso modello a moduli, la differenza è che rispetto a quello che sto realizzando ora quella è preistoria :-D.

Il motivo è semplice: quando siamo partiti con la realizzazione di quel prodotto non sapevamo (io e il cliente) bene dove stavamo andando e alla fine è diventato un “macello”, questo macello è la causa, buona e giusta, di questo studio e dell’entrata in staging di test della prima versione del prodotto nuovo, con un solo modulo per ora, proprio ieri :-)

Nella versione precedente i moduli avevano la velleità di non sapere come la shell avrebbe visualizzato la parte di commanding ed io ero impazzito non poco per astrarre la parte di comunicazione/inizializzazione del singolo modulo per far si che potesse comunicare con la shell descrivendo quello di cui aveva bisogno lasciando libertà alla shell di visualizzarlo come meglio credeva… se la cosa da un lato è fattibile dall’altro è decisamente limitante perchè descrivere/astrarre il concetto di menu/menuItem è abbsatanza semplice mentre se pensiamo al Ribbon la cosa diventa sostanzialmente impossibile.

Un’obiezione che si può fare è però che in questo modo Shell e Moduli si legano a filo doppio perchè se la Shell decide di cambiare il Ribbon e passare ad altro il tutto si “rompe”… è un problema? secondo me neanche lontanamente, è un requisito (punto), se poi siamo strati diligenti e abbiamo applicato bene M-V-VM allora scopriamo che assorbire questa “rivoluzione” diventa molto facile, ma proprio molto facile.

Ci sono però aree in cui potrebbe avere senso astrarre, lo sto valutando per una nuova milestone. L’idea è questa:

• Uno dei moduli che vengopno caricati dalla Shell è la “Dashboard”: la dashboard è una sorta di Start Page di Visual Studio configurabile a piacere dall’utente, una cosa molto simile, per chi ha provato, alla home page di SharePoint;
• Ogni modulo in fase di inizializzazione ha l’opportunità di informare la dashboard che lui contiene una o più parti (dei banalissimi UserControl) che rende disponibili per la visualizzazione nella dashboard stessa;
• L’utente infine ha la possibilità di scegliere quali “parti” visualizzare e come visualizzarle;

Qui potrebbe avere senso imporre che lo UserControl, che rappresenta una “parte”, implementi una cerca interfaccia e deleghi alla dashboard alcune scelte di visualizzazione al fine di mantenere coerenza grafica tra le varie parti… ma in questo caso è facile.

Commenti, idee?

.m