Technology Experience
.NET World

Lightswitch: come rendere invisibile un controllo, agendo sulla UI

Questo post inizia con la fatidica frase “A due controlli è stato fatto del male durante la stesura di questo post”.
Prima vi spiego come risolvere il vostro problema, poi vi dico perchè questa cosa in fondo non mi piace poi molto.

Dunque, lo scopo è quello di rendere invisibile un controllo (TextBox, CheckBox, ComboBox, insomma…qualsiasi cosa che erediti da System.Windows.Controls.Control), in base al valore contenuto in un altro controllo. La cosa è nata in questo thread sui forum di lightswitch.it. In pratica, abbiamo due controlli: una TextBox ed una CheckBox. Entrambe sono bindate a due entity property diverse: quando la TextBox (usata per inserire il valore di uno stipendio) contiene “0”, la CheckBox (usata per inserire Contributi si/no) deve essere resa invisibile, altrimenti no. Come fare?

Io ho risolto in questo modo.

Analogamente a quanto fatto in un mio post precedente, vado a gestire l’evento Created dello screen che mi interessa:

partial void TeamsListDetail_Created() {  }

 

In questo modo, grazie ad un bel giochino di C# e lambda, scrivo poche righe di codice:

this.FindControl("CheckBox").ControlAvailable += (s, e) =>
{
checkbox = e.Control as CheckBox;
};

this.FindControl("TextBox").ControlAvailable += (s, e) =>
{
textbox = e.Control as TextBox;
textbox.TextChanged += (s2, e2) =>
{
checkbox.Visibility = textbox.Text.Equals("0") ? System.Windows.Visibility.Collapsed :
System.Windows.Visibility.Visible;
};
};

 

In breve, cerco di riassumere:

  • ottengo i riferimenti ai due controlli, rispettivamente chiamati “CheckBox” e “TextBox” – ovviamente i vari nomi vengono assegnati da Lightswitch, ma possono essere modificati
  • quando si scatena l’evento ControlAvailable della CheckBox, non faccio nulla di particolare: semplicemente mi vado a salvare il riferimento per usarlo dopo
  • quando si scatena l’evento ControlAvailable della TextBox, ne sottoscrivo l’evento TextChanged
  • ogni volta che l’utente cambia il testo contenuto nella TextBox, si scatena l’evento TextChanged – questo lo sappiamo bene, è il runtime di Silverlight. A questo punto è molto semplice, perchè faccio un banale controllo: quando la TextBox contiene “0” la CheckBox sparisce, altrimenti compare
  • notare che Lightswitch sulla UI produce anche la label della nostra proprietà (oltre al controllo per editare la proprietà stessa): la Label non è sotto il nostro controllo, per cui non potremo mai renderla invisibile/visibile (attendo correzioni se sbaglio Con la lingua fuori)

La soluzione c’è, e devo dire anche con poche righe di codice.
Sorriso

Perchè è stato fatto del male a questi due controlli? Per due motivi principali.

  • Innanzitutto è stata inserita una logica di business a livello di UI. Il fatto che la proprietà booleana Contributi debba essere false quando lo stipendio è zero mi sembra una regola del dominio (non è un’applicazione che sto sviluppando, perciò prendo per buona questa regola). Però questo non dovrebbe essere inserito nella UI, ma sulle entity vere e proprie. E’ per questo che ho consigliato di agire sulla entity, così questa regola viene “riciclata” indipendentemente dal fatto che venga utilizzato quello screen. Importantissimo!!! Quindi, per esempio, basta andare nel set della proprietà Stipendio e – se vale zero – metto a false la proprietà Contributo. Sia chiaro: questo non rende invisibile la CheckBox, si assicura solamente che i dati nelle entità di dominio siano valorizzate coerentemente con quello che il dominio vuole e si aspetta.
  • Il secondo errore è che scriviamo codice molto, molto specifico rispetto alla tecnologia del presentation layer. Come ha già osservato Alessandro Del Sole qualche giorno fa, oggi Lightswitch produce in output un’applicazione Silverlight. Ma in futuro potrebbe produrre HTML5, applicazioni Metro-style, WPF, e chissà cos’altro. Quando quel “futuro” sarà “presente”, saremo costretti a riprendere l’applicazione e a riscrivere quella parte. Uno dei vantaggi di Lightswitch è l’autogenerazione dinamica della UI, e se noi andiamo a metterci lo zampino, ne paghiamo e pagheremo le conseguenze.

Alla prossima!

Send to Kindle

Igor Damiani

La sua passione per l'informatica nasce nella prima metà degli anni '80, quando suo padre acquistò un Texas Instruments TI-99. Da allora ha continuato a seguire l'evoluzione sia hardware che software avvenuta nel corso degli anni. E' un utente, un videogiocatore ed uno sviluppatore software a tempo pieno. Igor ha lavorato e lavora anche oggi con le più moderne tecnologie Microsoft per lo sviluppo di applicazioni: .NET Framework, XAML, Universal Windows Platform, su diverse piattaforme, tra cui spiccano Windows 10 piattaforme mobile. Numerose sono le app che Igor ha creato e pubblicato sul marketplace sotto il nome VivendoByte, suo personale marchio di fabbrica. Adora mantenere i contatti attraverso Twitter e soprattutto attraverso gli eventi delle community .NET.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.