WPF, LINQ e DataBinding

WPF, LINQ e Binding
Con questo articolo voglio giocare con un paio di nuone tecnologie offerte da Microsoft.
Seguendo l’esempio offerto da Beatriz Costa al TechEd 2008, ho sviluppato qualcosa di analogo.
Librerie e Libri
L’esempio in se non è nulla di complicato ma è bello poter vedere in azione queste nuove tecnologie.
Il progetto che andremo a realizzare con VS2008 sarà un WPF Browser Application.
La nostra pagina principale sarà Page1.xaml e aggiungeremo solamente 3 files in più al progetto:
 
XMLFile1.xml
Questo sarà il nostro file d’appoggio, il quale conterrà le informazioni che vogliamo presentare all’utente.
Parte del contenuto di questo file si presenta così:
<ListBooks>
<BookObjectTitle="Extreme Programming Explained: Embrace Change">
<
ImageFileName>Images\xp_guide_small.jpg</ImageFileName>
<
Author>Kent Beck</Author>
<
Published>25 Nov 2004</Published>
</BookObject>
Notate, avrete bisogno di una directory Images dove dovrete andare a inserire l’immagine da caricare relativa al libro.
BookObject
Questa è una semplicissima classe contenitore che useremo per definire un libro all’interno della nostra libreria.
    public class BookObject
    {
        public string Title { get; set; }
        public string ImageFileName { get; set; }
        public string Author { get; set; }
        public string Published { get; set; }
 
        public override string ToString()
        {
            return Title + " " + Author;
        }
    }
 
Library
Finalmente un pò di codice.
    public class Library
    {
        public Library()
        {
            Uri res = new Uri(@"pack://application:,,,/XMLFile1.xml", UriKind.Absolute);
 
            // The Application object wraps a set of XAML files and creates a shared data environment between the
            // pages. The Application object loads with the initial load and provides shared variables at that time.
            StreamResourceInfo sri = App.GetResourceStream(res);
            StreamReader reader = new StreamReader(sri.Stream);
            XDocument booksXml = XDocument.Load(reader);
 
            _libraryObjects = new List<BookObject>();
 
            var book = from books in booksXml.Descendants("BookObject")
                       select new BookObject
                       {
                           Title = books.Attribute("Title").Value,
                           ImageFileName = books.Element("ImageFileName").Value,
                           Author = books.Element("Author").Value,
                           Published = books.Element("Published").Value
                       };
 
            foreach (var bd in book)
                _libraryObjects.Add(bd);
        }
 
        private List<BookObject> _libraryObjects;
        public List<BookObject> LibraryObjects
        {
           get { return _libraryObjects; }
        }
    }
 
Analizziamo nel dettaglio il lavoro di questa classe.
Per prima cosa dovrà aprire il nostro file XMLFile1.xml e leggerne il contenuto.

Per motivi di sicurezza i progetti di questo tipo, Browser Application, non hanno diritti di lettura e scrittura sul nostro file system se non nelle directory utilizzate da IsolatedStorageFile.
Per questo motivo dovremo specificare nelle proprietà del XMLFile1.xml:
·         Build Action: Resource
In questa maniera il file verrà inserito all’interno del nostro eseguibile e sarà disponibile per la lettura.

Per poter leggere il file, WPF, mette a disposizione le
URI (uniform resource identifiers).
Quindi specificheremo un nuovo URI, puntando sul file all’interno della nostra applicazione.
Avendo adesso il riferimento al nostro file, dobbiamo farlo leggere a LINQ che non è a conoscenza di come sono organizzate le nostre risorse.
Quindi andremo a prendere la risorsa tramite la classe Application.
La classe Application è un’interfaccia tra il nostro sistema e l’applicazione. È l’entry point delle nostre applicazioni WPF.
Nel nostro caso specifico, troveremo questa nel file App.xaml.cs
Per ulteriori informazioni
quì.
Acquisito il riferimento al nostro file e creati gli Streams opportuni, lasceremo a LINQ l’arduo compito di leggere i dati all’interno del file.
Questo procedimento è alquanto semplice, almeno nel nostro caso.
Creando una query come quella all’interno del nostro codice, LINQ si occuperà di tirar fuori tutti i dati relativi ai libri presenti nel file XML e inserirà questi dati all’interno della variabile book.
Adesso che abbiamo a disposizione tutti i dati che sono all’interno del nostro file xml, ne inseriremo i riferimenti all’interno della nostra collection:
List<BookObject> _libraryObjects;
 
Page1.xaml
A questo punto la nostra applicazione è pronta all’80%.
Ci rimane solamente da bindare i dati all’interno della nostra pagine XAML e definire come vogliamo visualizzarli.
Per quanto concerne il concetto di bindare i dati all’interno di un’applicazione WPF vi consiglio di vedere il video di Beatriz Costa, il quale vi potrà chiarire le idee.
Sappiate solamente che il binding è una relazione che creiamo tra la nostra UI e la nostra sorgente di dati.

Quello che vedremo in questo tutorial è come bindare dei dati presenti in memoria che vengono modificati durante l’esistenza dell’applicazione.
    <StackPanel x:Name="LayoutRoot" HorizontalAlignment="Center" VerticalAlignment="Top">
        <ListBox ItemsSource="{Binding Source={StaticResource myLibrary}, Path=LibraryObjects}"
            ScrollViewer.VerticalScrollBarVisibility="Auto" Height="480" Width="500" />
        <!--<ComboBox ItemsSource="{Binding Source={StaticResource myLibrary}, Path=LibraryObjects}" SelectedIndex="0"/>-->
    </StackPanel>
Con queste poche righe di XAML noi stiamo già bindando i nostri dati e potrebbero essere già disponibili.
Se non ci credere, provate a completare in questa maniera:
·         Inserite il seguente codice sopra lo StackPanel poc’anzi definito:
    <Page.Resources>
        <local:Library x:Key="myLibrary" />
Ecco adesso la vostra ListBox con i dati bindati.
Già così abbiamo ottenuto ciò che volevamo ma, per concludere, diamo un’aspetto migliore ai nostri dati.
Per far ciò dobbiamo solamente dire a WPF come vogliamo, appunto, visualizzarli.
Per farlo bisogna utilizzare un
DataTemplate.
Il nostro DataTemplate è stato definito nella seguente maniera:
        <DataTemplate DataType="{x:Type local:BookObject}">
            <StackPanel Orientation="Horizontal" Margin="3" TextBlock.FontSize="12" TextBlock.FontFamily="Tahoma">
                <Image Source="{Binding Path=ImageFileName}" Margin="0,0,3,0" />
                <StackPanel Width="500">
                    <TextBlock FontWeight="Bold" Text="{Binding Title}" />
                    <StackPanel Orientation="Horizontal">
                        <TextBlock Text="{Binding Author}" />
                        <TextBlock Text="{Binding Published}" />
                    </StackPanel>
                </StackPanel>
            </StackPanel>
        </DataTemplate>
    </Page.Resources>
In pratica stiamo definendo i StackPanel che conterranno i nostri dati, cosa dovranno contenere e come visualizzarli.
Esempio, il primo StackPanel definisce come il testo verrà visualizzato e al suo interno ha un Controllo di tipo Image che viene bindato all’oggetto ImageFileName presente all’interno della classe BookObject.
 
Nel codice ho lasciato commentato un Control di tipo ComboBox.
Provate a decommentare la ComboBox e a commentare la ListBox, e potrete capire come le WPF vi aiuteranno a relazionarvi e come sono strettamente relazionate a pattern quali MVP.
Il progetto completo lo trovate quì.
 
Tags:

SDL (Parte 5: Inizio del progetto)

Inzio del progetto
All’inizio di un progetto bisogna seguire pochi ma importanti passi:
·         Determinare se l’applicazione è coperta dal SDL
·         Dichiarare un Security Advisor
·         Creare un team di Security Leadership
·         Creare il processo di bug-tracking, security e privacy bug
·         Creare una bug bar
 
Utilizzare una procedura SDL non può far altro che creare benefici per il
software da sviluppare.
Comunque i software che incontrano uno o più dei seguenti criteri, ottengono
maggior beneficio:
·         Utilizzano o creano dati di business: email, database etc
·         Salvano, processano o comunicano personally identifiable
information
(PII): dati finanziari, medici, dati sensibili, etc
·         Software sempre online: instant messaging ...
·         Software prodotto per andare online: browser ...
·         Software esposto all’online: giochi, servizi mobili
·         Prodotti con updates automatici
 
Nominare un responsabile che guiderà il team tramite i processi SDL,
puntando all’ottenimento del Final Security Review (vedremo nei prossimi
capitoli cos’è).
La scelta di tale figura dipende molto da come la tua azienda è strutturata.
Se l’azienda ha già un security team allora si potrebbe riutilizzare la figura
presente in quel team oppure la più capace di quel team.
È importante che la figura abbia ottime capacità nei processi di managment
dei progetti e, ovviamente, sulla sicurezza.
I suoi compiti saranno:
·         Testa di ponte tra il team di sviluppo e il team della sicurezza
·         Gestire i meeting di SDL con il team di sviluppo
·         Gestire il design a il threat-model con il team di sviluppo
·         Analisi e suddivisione dei bug di sicurezza e privacy
·         Security Sounding Board
·         Preparare il team di sviluppo all’FSR
·         Lavorare con security team esterni
Prima della creazione del processo SDL, la comunicazione tra il gruppo di
produzione e quello della sicurezza sarà alquanto arduo. Il Security Advisor
sarà il punto di contatto del gruppo di sviluppo.
Facendone parte del gruppo di sviluppo e al tempo stesso avendo le
conoscente acquisite sulla sicurezza potrà far da traduttore tra le due aree.
Prima che lo sviluppo parta bisogna presentare gli obbiettivi e i punti chiavi
del processo SDL. Sarà al massimo una presentazione di un’ora.
Il Security Advisor dovrà parlare con il team di sviluppo riguardo il design e
dell’architettura scelta.
Dovrà controllare se:
·         L’applicazione ha una piccola o inesistente superfice d’attacco
·         L’applicazione usa le appropriate best practices di sviluppo
·         Segue il secure design
·         Il threat model è completo e riflette come il sistema si difende
·         C’è un sistema appropriato di testing
I bug di sicurezza e privacy dovranno essere evidenziati durante il processe
di sviluppo e correttamente suddivisi e trattati.
Il Security Advisor indirizzerà le domande di sicurezza e privacy, ed eventuali
idee al team di sviluppo.
Dovrà anche incoraggiare ad avere e proporre nuove idee.
In Microsoft questo flusso di idee è gestito nella seguente maniera:

 

È un compito fondamentale dell’Advisor, ovvero esser sicuri che l’FSR sia
coperto al 100% e che tutti i fondamenti dell’SDL siano stati gestiti.
Se qualcuno d’esterno vi avverte di un bug sul vostro software, non preoccupatevi.
Quest’informazione vi farà risparmiare un sacco di tempo.
 
Questo team si occupa della comunicazione tra i vari team, schedulazione delle
attività etc.
I task del team includono:
·         Regolare comunicazione al team di sviluppo sui bugs di sicurezza e la
privacy trovati
·         Comunicazione su aggiornamenti riguardo privacy e sicurezza
Sembra solamente una montagna di parole ed email da scrivere ma, in realtà,
per grossi progetti software questo processo è ottimo per tener aggiornati i teams
su privacy e sicurezza.
 
È importantissimo che i bug di sicurezza e privacy vengano tracciati correttamente.
Ecco come:
·         Effetto bug sicurezza/privacy
·         Causa bug sicurezza/privacy
Questi, a loro volta, avranno dei valori predefiniti, effetti:
·         Non ci interessa
·         Spoofing
·         Tampering
·         Repudiation
·         Information Disclosure
·         Information Disclosure (privacy)
·         Denial of Service
·         Elevation of Privilege
·         Attack Surface Reduction
Cause:
·         Non ci interessa
·         Buffer Overflow or Underflow
·         Arithmetic Error (ex: integer overflow)
·         SQL/Script Injection
·         Directory Traversal
·         Race Condition
·         Cross-Site Scripting
·         Cryptographic Weakness
·         Weak Authentication
·         Weak Authorization/Inappropriate ACL
·         Ineffective Secret Hiding
·         Resource Consumption (DoS)
·         Incorrect/No Error Message
·         Incorrect/No Pathname Canonicalization
·         Other
 
Bug Bar
Bisognerà decidere che tipo di bugs si andranno a fixare durante lo
sviluppo del progetto.
Definire una Bug Bar ci chiarisce su cosa dobbiamo fixare, cosa
verrà parzialmente risolto e cosa potremmo lasciare stare.
 
 

Tags: