Applicazione per la gestione di liste integrata con Facebook - Università degli Studi di Padova - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica
Corso di Laurea in Informatica
Applicazione per la gestione di liste
integrata con Facebook
Tesi di Laurea
Relatrice
Prof.ssa Ombretta Gaggi
Laureando
Marco Michielotto
Anno Accademico: 2014-2015
Applicazione per la gestione di liste integrata con Facebook
Marco Michielotto, Tesi di laurea, ©Ottobre 2015
Sommario
Il presente documento descrive il dettaglio dello stage formativo intrapreso dal lau-
reando Marco Michielotto presso l’azienda Noonic s.r.l., della durata di 320 ore. Lo
Stage aveva come obiettivo lo sviluppo di un applicativo Web per la gestione e la com-
pilazione di liste di elementi generici in una sorta di minigioco integrato con il social
network Facebook.
Si andranno dunque a riassumere le attività svolte durante lo stage, con particolare
attenzione agli strumenti e alle tecnologie utilizzate.
iii
Ringraziamenti
Vorrei innanzitutto ringraziare la professoressa Ombretta Gaggi, relatrice della mia te-
si, per la disponibilità e l’aiuto offertomi.
Ringrazio inoltre tutto il team di Noonic s.r.l. ed in particolare il tutor aziendale
Sebastiano Favaro, per avermi accolto nel loro ufficio ed avermi sempre fatto sentire
come a casa e parte integrante del gruppo.
Desidero poi ringraziare i miei genitori e mio fratello per avermi sostenuto ed aiu-
tato in questi intensi anni di studio, senza i quali non sarei mai giunto fin qui.
Un sentito ringraziamento va a tutti i miei amici e compagni di università per i bel-
lissimi momenti passati assieme, per essermi stati vicini e avermi sopportato durante
questi anni di studi.
Padova, Ottobre 2015 Marco Michielotto
v
Indice
1 Introduzione 1
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Proposta di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Pianificazione 3
3 Analisi dei Requisiti 5
3.1 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 Caso d’uso UC 1.3: Gestione liste . . . . . . . . . . . . . . . . . 7
3.1.2 Caso d’uso UC 1.3.1: Creazione nuova lista . . . . . . . . . . . . 8
3.1.3 Caso d’uso UC 1.5: Compilazione nuova lista . . . . . . . . . . . 9
3.1.4 Caso d’uso UC 1.5.4: Visualizzazione risultato sintetico . . . . . 10
3.2 Elenco dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Requisiti Funzionali . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2 Requisiti qualitativi . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3 Requisiti dichiarativi . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Resoconto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Progettazione 15
4.1 Dominio applicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Architettura generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Progettazione del Model . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1 Progettazione del Database . . . . . . . . . . . . . . . . . . . . 19
4.4 Progettazione del Controller . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.2 Architettura del Controller . . . . . . . . . . . . . . . . . . . . . 21
4.4.3 FacebookSDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.4 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Progettazione delle View . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6 Diagrammi delle attività . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6.1 Attività principale . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6.2 Compilazione di una lista . . . . . . . . . . . . . . . . . . . . . 28
4.6.3 Gestione liste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6.4 Gestione risultati liste . . . . . . . . . . . . . . . . . . . . . . . 31
vii
viii INDICE
5 Implementazione e testing 33
5.1 Strumenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Implementazione del backend . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.1 Autenticazione con Facebook . . . . . . . . . . . . . . . . . . . 33
5.2.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3 Implementazione dell’interfaccia . . . . . . . . . . . . . . . . . . . . . . 38
5.3.1 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.2 Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.3 Compilazione Lista . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.4 Creazione e gestione delle liste . . . . . . . . . . . . . . . . . . . 45
5.4 Metriche di progettazione e codifica . . . . . . . . . . . . . . . . . . . . 48
5.5 Verifica e Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.1 Test di verifica . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.2 Test di validazione . . . . . . . . . . . . . . . . . . . . . . . . . 49
6 Conclusioni 51
6.1 Obiettivi raggiunti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A Design Pattern utilizzati 53
A.1 Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.2 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Glossario 55
Bibliografia 61
Capitolo 1
Introduzione
1.1 L’azienda
Noonic s.r.l. è una web agency e digital factory, fondata da tre giovani ragazzi nel
2012, che opera in Italia e in India. La sede legale si trova a Milano, l’ufficio operativo
a Padova e una sede di sviluppo a Trivandrum.
L’azienda si occupa di sviluppo di applicativi web e recentemente anche di applica-
zioni per smartphone, garandendo al cliente anche soluzioni di web marketing per il
raggiungimento degli obiettivi di business e comunicazione dell’azienda.
Figura 1.1: logo dell’azienda
1.2 Proposta di stage
Il progetto proposto dall’azienda riprende un’idea già sviluppata alcuni anni fa, che
riscontrò molto successo in Italia (più di 10 milioni di utilizzi). Consiste nel realizzare
un applicativo web, all’interno del quale l’utente si sottopone alla compilazione di alcu-
ne liste di elementi, dalle quali può scegliere gli elementi di proprio interesse (secondo
il tema per cui è stata creata la stessa lista).
Ad esempio potrà esserci una lista di sport dalla quale l’utente potrà scegliere quali
ha praticato, oppure una lista di libri dove selezionare quelli letti e l’applicazione darà
la possibilità di condividere il risultato con gli amici. L’idea è dunque quella di un
mini gioco sociale all’interno del quale gli utenti condividono aspetti della loro vita
1
2 CAPITOLO 1. INTRODUZIONE semplicemente selezionando elementi da liste pre-create da altri utenti, rendendo così minimo lo sforzo da parte del giocatore. L’applicazione è integrata con il social network Facebook, sfruttando il sistema Canvas Frame. All’utente, dopo la compilazione di una lista viene presentato un risultato aggregato contenente solo il numero di elementi selezionati come ad esempio: "Hai selezionato 15 sport su 63". Il risultato ottenuto potrà essere condiviso su Facebook invogliando così gli amici dell’utente a vedere nel dettaglio quanto selezionato dall’utente e l’amico stesso verrà invitato ad effettuare il questionario. La Web App prevede sia la funzionalità di compilazione delle liste, sia la possibilità, da parte di qualsiasi utente, di crearne; questo rende meno gravoso il popolamento della piattaforma agli sviluppatori della stessa. Infine dalla pagina di gestione del- le liste create, l’utente può controllare quante volte è stata compilata ciascuna lista, indicandone il livello di popolarità. Lo scopo principale era quello di sviluppare nuo- vamente questo applicativo, sfruttando le nuove tecnologie disponibili, da immettere sul mercato indiano, nel quale l’azienda è molto presente. L’applicazione è sviluppata in lingua inglese poiché una delle lingua ufficiali dell’in- dia.
Capitolo 2
Pianificazione
Prima dell’inizio dello stage è stato redatto un piano di lavoro, proposto dall’azianda,
a cadenza settimanale che è stato ampiamente rispettato.
• Prima settimana: Fase di studio delle tecnologie coinvolte: API di Facebook,
Laravel, PHP, HTML, CSS, Javascript, MySQL;
• Seconda settimana: Fase di studio parziale, inizio della fase di analisi, colle-
zione dei requisiti ed inizio della stesura di un documento di analisi dei requisiti;
• Terza Settimana: Fine della fase di analisi ed inizio della fase di realizzazione
della specifica tecnica;
• Quarta Settimana: Sviluppo del prodotto;
• Quinta Settimana: Sviluppo del prodotto, fino al rilascio di una versione alpha;
• Sesta Settimana: Fine dello sviluppo ed inizio della fase di test funzionali,
rilascio di una versione beta;
• Settima Settimana: Validazione ulteriore parte dell’azienda con relative corre-
zioni, e messa online del progetto. (circa una versione di RC);
• Ottava Settimana: Correzioni a seguito di bug presentati dagli utilizzatori,
monitoraggio dell’utilizzo, miglioramenti a seguito della messa online, ulteriori
potenziali sviluppi.
34 CAPITOLO 2. PIANIFICAZIONE
Capitolo 3
Analisi dei Requisiti
In questo capitolo viene documentata l’attività di analisi dei requisiti del progetto
proposto.
3.1 Casi d’uso
Per favorire l’attività di estrazione dei requisiti, a seguito di una riunione con il tutor
interno, sono stati redatti dei casi d’uso, dai quali è stato possibile estrarre un numero
consistente di requisiti. Per ogni caso d’uso è stato redatto il rispettivo diagramma
seguendo le specifiche UML 2.0, accompagnato con una descrizione testuale, secondo
lo schema seguente:
UC: Il nome del caso d’uso con un codice identificativo gerarchico;
• Attori Principali: Gli attori coinvolti;
• Precondizioni: La precondizione del caso d’uso;
• Descrizione: La descrizione del caso d’uso;
• Post-condizioni: La Post-condizione del caso d’uso;
• Scenario Alternativo: L’eventuale caso d’uso alternativo.
Caso d’uso UC 1: Visione ad alto livello
• Attori: utente, nuovo utente;
• Precondizione: l’utente è autenticato su Facebook;
• Descrizione: Al momento dell’apertura dell’app l’utente di Facebook ha la pos-
sibilità, in stile gioco, di compilare delle liste tra quelle proposte e di gestire la
creazione di nuove liste da sottoporre ad altri utenti. Inoltre nel caso l’utente
provenga da un link della bacheca di Facebook ha la possibilità di visualizzare
i risultati della persona che ha condiviso il risultato. Infine se l’utente ha già
utilizzato l’app e dunque ha già compilato almeno una lista, potrà visualizzarne
i risultati ottenuti;
56 CAPITOLO 3. ANALISI DEI REQUISITI
Figura 3.1: Caso d’uso UC1: Visione ad alto livello
• Post-condizione: l’utente ha selezionato l’operazione da eseguire;
• Scenario alternativo: se l’utente richiede la visualizzazione dei risultati di un
amico riguardo una lista che lui stesso non ha ancora compilato, viene esortato a
sottoporsi ad essa tramite un messaggio di notifica.3.1. CASI D’USO 7
3.1.1 Caso d’uso UC 1.3: Gestione liste
Figura 3.2: Caso d’uso UC 1.3: Gestione liste
• Attori: utente, nuovo utente;
• Precondizione: l’utente è autenticato su Facebook;
• Descrizione: Il nuovo utente può solamente iniziare la procedura per crearne una
nuova; mentre un utente che ha già utilizzato l’app potrà, se presente, modificare
una lista già creata;
• Post-condizione: l’utente procede con la compilazione, modifica o ripresa della
creazione di una lista;
• Scenario alternativo: se l’utente aveva lasciato in sospeso la creazione di una
lista, avrà la possibilità di riprenderla.8 CAPITOLO 3. ANALISI DEI REQUISITI
3.1.2 Caso d’uso UC 1.3.1: Creazione nuova lista
Figura 3.3: Caso d’uso UC 1.3.1: Creazione nuova lista
• Attori: utente;
• Precondizione: l’utente sta creando una nuova lista da poter sottoporre ad altri
utenti di Facebook;
• Descrizione: l’utente durante la procedura di creazione di una nuova lista ha
la possibilità di inserire ordinatamente un titolo, un’immagine, una descrizione e
infine gli elementi testuali che dovrà contenere;
• Post-condizione: la lista è stata creata correttamente.3.1. CASI D’USO 9
3.1.3 Caso d’uso UC 1.5: Compilazione nuova lista
Figura 3.4: Caso d’uso UC 1.5: Compilazione nuova lista
• Attori: utente;
• Precondizione: l’utente vuole sottoporsi alla compilazione di una lista;
• Descrizione: l’utente procede con la compilazione della lista selezionando gli
elementi che ritiene di suo interesse (secondo il titolo e la descrizione della lista)
e può sosparsi tra gruppi di elementi per favorirne la leggibilità. Infine l’utente
può concludere la compilazione e vedrà visualizzato un risultato riassuntivo che
potrà condividere nella bacheca di Facebook;
• Postcondizione: l’utente ha compilato la lista desiderata.10 CAPITOLO 3. ANALISI DEI REQUISITI
3.1.4 Caso d’uso UC 1.5.4: Visualizzazione risultato sintetico
Figura 3.5: Caso d’uso UC 1.5.4: Visualizzazione risultato sintetico
• Attori: utente;
• Precondizione: l’utente ha concluso la compilazione di una lista;
• Descrizione: viene data la possibilità all’utente di rivedere gli elementi che ha
selezionato nella lista appena compilata, di sceglierne un’altra tra quelle proposte
dall’applicazione a quale sottoporsi o di visualizzare i risultati che hanno ottenuto
i suoi amici che si sono sottoposti alla medesima lista. Infine è possibile pubblicare
i risultati ottenuti sulla propria bacheca di Facebook;
• Postcondizione: l’utente ha selezionato l’operazione da eseguire.3.2. ELENCO DEI REQUISITI 11
3.2 Elenco dei requisiti
A seguito della stesura dei casi d’uso è stato possibile redigere la seguente lista di re-
quisiti. Ogni requisito deve essere classificato nella seguente maniera:
R[rilevanza][tipo][codice]
dove:
• rilevanza può assumere i seguenti valori:
– 0. obbligatorio;
– 1. desiderabile;
– 2. facoltativo.
Tale attributo dovrà essere rappresentato per mezzo del numero corrispondente.
• tipo può assumere i seguenti valori:
– F. funzionale;
– Q. qualitativo;
– D. dichiarativo.
Tale attributo dovrà essere rappresentato dalla lettera corrispondente.
• codice è univoco e identificativo del singolo requisito. Il codice viene inoltre
usato per creare una gerarchia tra requisiti. Dato il requisito “A” questo sarà
soddisfatto se e solo se tutti i suoi sotto-requisiti obbligatori saranno soddisfatti.
Si elencano sotto tutti i requisiti individuati, suddivisi per tipologia.
3.2.1 Requisiti Funzionali
Requisito Rilevanza Descrizione
R0F1 Obbligatorio L’applicazione web deve presentare in ho-
mepage un elenco di liste, rappresentate da
un’immagine ed un titolo, a cui l’utente può
sottoporsi.
R0F1.1 Obbligatorio L’elenco delle liste deve essere un sottoinsie-
me di quelle presenti nel sistema, scelte tra
le più popolari o nuove, ma comunque non
ancora utilizzate dall’utente.
R2F1.2 Opzionale La logica di visualizzazione delle liste in ho-
mepage può essere cambiata dal pannello
configurazione.
R0F2 Obbligatorio L’utente quando si sottopone ad una lista
composta da n elementi, ha la possibilità di
sceglierne un numero che va da zero a n.
Continua nella pagina successiva.12 CAPITOLO 3. ANALISI DEI REQUISITI
Continua dalla pagina precedente.
Requisito Rilevanza Descrizione
R0F2.1 Obbligatorio Ogni lista contiene un numero di elementi va-
riabile, ma limitato ad un massimo di 100.
R0F2.2 Obbligatorio Le liste sono presentate all’utente per pa-
gine con 10 elementi ciascuna per garantire
l’accessibilità.
R0F2.2.1 Obbligatorio Il numero di elementi per pagine è modifi-
cabile tramite variabile di configurazione di
Laravel.
R0F2.3 Obbligatorio Ogni lista è composta, oltre che da un insie-
me di elementi, da un titolo ed un’immagine.
R0F2.4 Obbligatorio Quando l’utente termina la compilazione
di una lista verrà visualizzato un risultato
aggregato.
R0F2.5 Obbligatorio Quando l’utente termina la compilazione di
una lista potrà visualizzare i risultati aggre-
gati e dettagliati degli amici Facebook che
hanno compilato la stessa.
R0F3 Obbligatorio L’utente può visualizzare i risultati dettaglia-
ti di utenti Facebook solamente se ha già
compilato la lista corrispondente.
R0F3.1 Obbligatorio Nel caso l’utente cercasse di visualizzare i ri-
sultati di un utente Facebook circa una lista
che non ha ancora compilato, una notifica lo
esorterà a sottoporsi a quest’ultima.
R0F4 Obbligatorio Gli utenti dell’applicazione possono gestire
la creazione di nuove liste da pubblicare e
sottoporre ad altri utenti.
R0F4.1 Obbligatorio L’utente può creare nuove liste inserendo un
titolo, un’immagine e una lista di elementi.
R0P4.1.1 Obbligatorio Le pagine di creazione delle liste sono in real-
tà un’unica pagina dinamica gestita tramite
Javascript per ridurre il carico lato server.
R2F4.1.2 Opzionale L’inserimento delle immagini è gestito con
una ricerca in Google immagini.
R1F4.2 Desiderabile L’utente ha la possibilità di modificare una
lista creata, ma la modifica non altererà in
alcun modo i risultati degli utenti che l’hanno
già compilata.
Continua nella pagina successiva.3.2. ELENCO DEI REQUISITI 13
Continua dalla pagina precedente.
Requisito Rilevanza Descrizione
R1F4.3 Desiderabile L’utente può abbandonare e riprendere la
creazione di una nuova lista.
R0F4.4 Obbligatorio La funzionalità di gestione della liste è ac-
cessibile da ogni pagina dell’applicazione.
R0F5 Obbligatorio L’utente ha la possibilità di conoscere i ri-
sultati dettagliati, e quindi quali elementi ha
selezionato, di tutte le liste che ha compilato.
R0F5.1 Obbligatorio Assieme ai risultati è possibile visualizzare le
statistiche di tutti gli utenti in percentuale
per ogni elemento suddivise per sesso.
R0F6 Obbligatorio L’applicazione deve tracciare tutti i dati
che Facebook, di base, mette a disposizione
quando l’utente accetta di utilizzare l’App, in
particolare l’età (o un suo range), l’indirizzo
e-mail, il sesso e in più la lista degli amici.
R0F7 Obbligatorio Il sistema deve tenere traccia del numero di
utenti che si sono sottoposti ad ogni lista.
R0F8 Obbligatorio L’utente può condividere il risultato ottenu-
to dalla compilazione della lista sulla propria
bacheca di Facebook.
R0F8.1 Obbligatorio Il post in bacheca deve contenere l’immagine,
il risultato della lista e un link per visualiz-
zarne il risultato all’interno dell’applicazione.
R1F9 Desiderabile Gli utenti con permessi di amministrazione
possono visualizzare la lista di tutti i test
ordinata per utilizzo.
R1F9.1 Desiderabile Per ogni lista sono disponibili le statistiche
del tasso di abbandono e la lista di utenti
che l’hanno compilata.
R2D14 Opzionale Il sistema prevede un pannello di configu-
razione accessibile al di fuori di Facebook
tramite autenticazione.
Tabella 3.1: Tabella requisiti funzionali
3.2.2 Requisiti qualitativi
Nessun requisito qualitativo è stato individuato.14 CAPITOLO 3. ANALISI DEI REQUISITI
3.2.3 Requisiti dichiarativi
Requisito Rilevanza Descrizione
R0D10 Obbligatorio L’applicazione sarà in lingua inglese.
R0D11 Obbligatorio L’applicazione deve essere integrata in Face-
book, quindi sfruttare le API che il social net-
work mette a disposizione e sarà visualizzata
all’interno del Canvas Frame di Facebook.
R0D12 Obbligatorio La parte server side dell’applicazione deve
essere sviluppata utilizzando il framework
Laravel 5.0 ed il linguaggio PHP 5.4.
R0D13 Obbligatorio L’interfaccia web deve utilizzare le tecnologie
HTML5, CSS3 e Javascript.
Tabella 3.2: Tabella requisiti dichiarativi
3.3 Resoconto
In totale sono stati individuati 32 requisiti suddivisi tra tipologia e rilevanza nel modo
seguente:
Figura 3.6: suddivisione requisiti per tipologia Figura 3.7: suddivisione requisiti per rilevanzaCapitolo 4
Progettazione
Il capitolo presenta le tecnologie utilizzate per lo sviluppo dell’applicazione ed il riepi-
logo della progettazione dell’architettura generale.
4.1 Dominio applicativo
In questa sezione vengono presentate le tecnologie utilizzate per lo sviluppo dell’ap-
plicazione. Il linguaggio utilizzato per il progetto è PHP, in particolare la versione
5.5, ampiamente utilizzato durante il corso di studi, anche se mai utilizzato nella
programmazione ad oggetti, era abbastanza conosciuto.
Framework Laravel
L’applicazione è stata sviluppata utilizzando Laravel versione 5.0, un framework svi-
luppato in linguaggio PHP. L’utilizzo di questo framework è stato consigliato da parte
dell’azienda e ben si adattava alla natura del progetto proposto di applicazione web ad
elevata dinamicità.
Lo strumento era totalmente sconosciuto, ma lo studente aveva già avuto modo di
lavorare con un framework PHP durante il corso di Ingegneria del Software, dunque lo
studio è stato meno impegnativo.
Figura 4.1: Design pattern MVC
1516 CAPITOLO 4. PROGETTAZIONE
MySQL
Per la gestione dei dati consistenti dell’applicazione il proponente ha imposto l’utilizzo
di un database di tipo MySQL che si interfaccia con il modulo Eloquent ORM di
Laravel. La tecnologia era già ben conosciuta da parte dello studente, grazie a quanto
appreso durante il corso di studi.
Figura 4.2: logo MySQL
Facebook API
L’integrazione dell’applicazione avviene tramite le API ufficiali di Facebook, le quali,
essendo mal documentate, hanno costretto la perdita di alcune ore di studio aggiuntive,
per testare e capire al meglio il loro funzionamento.
Figura 4.3: logo facebook API
Bootstrap
Prima di progettare l’interfaccia grafica dell’applicazione è stato necessario decidere,
dopo aver scartato l’idea di scrivere a mano tutto il codice CSS, quale framework
utilizzare per velocizzare l’attività di sviluppo del front-end. Come consigliato anche
dalla comunity di Laravel, l’attenzione è ricaduta sul framework Bootstrap, il quale
ha facilitato la creazione di un interfaccia responsive e accessibile. Per il progetto è
stata utilizzata la versione 3 del suddetto framework, l’ultima disponibile al momento
dello scelta.4.2. ARCHITETTURA GENERALE 17
Figura 4.4: logo Bootstrap
Javascript
Linguaggio già ben noto grazie al corso di studi, Javascript è stato utilizzato in
particolare per alleggerire il carico del server nella paginazione e nella compilazione dei
form, sfruttando la tecnologia Ajax e le librerie JQuery.
Figura 4.5: logo Javascript Figura 4.6: logo Ajax Figura 4.7: logo jQuery
4.2 Architettura generale
Nel progettare l’architettura software si è seguito un approccio di tipo top-down, de-
scrivendo in un primo momento le componenti ad un alto livello di astrazione, per poi
scendere nel dettaglio. Il framework Laravel possiede una propria architettura strut-
turata secondo il design pattern MVC e questo a forzato l’utilizzo dello stesso anche
nella modellazione dell’architettura dell’applicazione. Le principali conponenti ad alto
livello sono:
• Model: contenente le classi che rappresentano rispettivamente le tabelle all’in-
terno del database, mappate dalle librerie di Eloquent ORM;
• View: insieme di file contenenti codice HTML e Template Blade che rappre-
sentano le pagine visualizzate all’utente;
• Controller: classi contenenti la logica dell’applicazione.18 CAPITOLO 4. PROGETTAZIONE
4.3 Progettazione del Model
Per la progettazione del Model si sono identificate le entità che contenessero i dati
dell’applicazione nelle seguenti:
• FacebookUser: che rappresenta il singolo utente registrato all’interno del social
network Facebook che utilizza l’applicazione;
• List: entità rappresentate la lista compilabile dagli utenti che contiene una serie
di elementi selezionabili;
• ListElement: elemento di una lista;
• FacebbokUserList: rappresenta il risultato ottenuto da un utente dopo aver
compilato una lista.
• Gui: modulo contenente le configurazioni riguardanti la grafica dell’applicazione,
come ad esempio il numero di elementi per pagina durante la fruizione di una
lista.
La componente FacebookUserList del Model, come si potrebbe pensare, sembrereb-
be non aggiungere nulla in più rispetto ad una relazione molti a molti fra FacebookUser
e ListElement. Ma come espressamente richiesto dal proponente dell’azienda, si vuole
mantenere il risultato, ottenuto dalla compilazione di una lista, salvato nel database
senza doverlo ogni volta calcolare per questioni di efficienza.
Dunque a discapito di una buona architettura si è scelto di aggiungere una classe in
più al Model, contenete queste informazioni.
In figura 4.8 sono rappresentate le componenti del Model e le rispettive relazioni.
Figura 4.8: Diagramma dell’architettura del model in Eloquent ORM4.3. PROGETTAZIONE DEL MODEL 19
4.3.1 Progettazione del Database
Viene ora presentata la struttura del database che mantiene la persistenza dei dati
dell’applicazione. Ogni componente del Model è stata tradotta in una tabella all’interno
del database e le relazioni molti a molti ( in questo caso una soltatnto) sono state
implementate aggiungendo una tabella ulteriore contenente le chiavi primarie delle
due tabelle facenti parte della relazione.
Il database è stato creato con lo Schema Builder di Laravel, che fornisce un mo-
do molto comodo di creare, modificare ed eliminare le tabelle del proprio database,
indipendentemente dal sistema usato. Laravel inoltre mette a disposizione una sorta
di version control del database detto Migration. Esso, tramite comandi da terminale,
permette di avviare delle procedure definite utilizzando lo Schema Builder, per creare
o modificare il database molto agevolmente.
Si riporta un esempio di migration, utilizzata per la creazione della tabella FacebookUser,
dove si può vedere come con la sola invocazione di due metodi statici della classe
Schema, è possibile creare le tabelle all’interno del database, indipendentemente dalla
tecnologia utilizzata.
1 class C re a t eF a c eb o o kU s e rs T a bl e extends Migration {
2 /* *
3 * Run the migrations .
4 *
5 * @return void
6 */
7 public function up ()
8 {
9 Schema :: create ( ' facebook_users ' , function ( Blueprint $ table )
10 {
11 $ table - > increments ( ' id ') ;
12 $ table - > bigInteger ( ' facebook_id ') -> unsigned () -> unique () ;
13 $ table - > string ( ' name ') ;
14 $ table - > string ( ' first_name ') ;
15 $ table - > string ( ' link ') ;
16 $ table - > string ( ' locale ') ;
17 $ table - > string ( ' email ') ;
18 $ table - > string ( ' gender ') ;
19 $ table - > integer ( ' admin ') -> default ( 0 ) ;
20 $ table - > boolean ( ' has_created ') ;
21 $ table - > timestamps () ;
22 }) ;
23 }
24
25 /* *
26 * Reverse the migrations .
27 *
28 * @return void
29 */
30 public function down ()
31 {
32 Schema :: drop ( ' facebook_users ') ;
33 }
34 }
Codice 4.1: classe migration per la creazione della tabella facebook_users20 CAPITOLO 4. PROGETTAZIONE
Di seguito viene mostrato lo schema del database così ottenuto.
Figura 4.9: Diagramma dell’architettura del database4.4. PROGETTAZIONE DEL CONTROLLER 21
4.4 Progettazione del Controller
Dopo aver definito le componenti del Model si è potuto procedere con la definizione
dell’architettura del controller.
4.4.1 Routing
In Laravel le richieste HTTP che provengono dall’esterno, vengono gestite e instradate
attraverso un sistema di routing. Esso permette di rispondere alle richieste esterne
dell’utente con la pagina WEB corretta. Consente infatti di definire il comportamen-
to dell’applicazione che si sta sviluppando, semplicemente associando una URI (cioè
un indirizzo Web, un file, un servizio, ecc.) ad una determinata funzione o Closure,
all’interno della quale lo sviluppatore inserisce l’azione corrisponde.
Un esempio di route in Laravel che visualizza la stringa “Hello world” alla richiesta
dell’utente della URL base del sito:
1 Route :: get ( '/ ' , function ()
2 {
3 return ' Hello ␣ World ';
4 }) ;
Codice 4.2: esempio di route
Una possibilità è quella di inserire tutta la logica dell’applicazione all’interno del file
route.php (contente le rotte) oppure di suddividerla utilizzando i controller. Essi sono
delle classi messe a disposizione dal framework, per strutturare al meglio il compor-
tamento del sito e, in caso di applicazione molto elaborata, permettere di creare una
buona architettura della logica.
Nell’applicazione sviluppata è stato gestito a livello di routing solamente l’instrada-
mento delle richieste ai vari controller, che si occuperanno di gestire il comportamento
generale del sito. Questo ha permesso progettare una gerarchia di classi controller in
modo da suddividere la logica del sito per macro-funzionalità e rendere il codice più
mantenibile.
4.4.2 Architettura del Controller
Nella progettazione dell’architettura del controller si è cercato di creare un compo-
nente per ogni funzionalità offerta dall’applicazione. Innanzi tutto una super classe
MainController, che eredita dalla classe Controller di Laravel, contiene il controllo
dell’autenticazione con il social network Facebook; da essa ereditano le seguenti classi:
• HomeController: si occupa della gestione della homepage e della visualizzazione
della pagina dei risultati ottenuti da un amico dell’utente (cioè la pagina che
verrà visualizzata nel momento in cui un utente clicca su un link all’interno della
propria bacheca);
• ListCreationController: contiene le funzioni che permettono la creazione di
nuove liste e la loro gestione (modifica e cancellazione);22 CAPITOLO 4. PROGETTAZIONE
• ListDrwaingUpController: controller che si occupa della compilazione delle liste
da parte degli utenti e della visualizzazione del risultato prima della condivisione
in bacheca.
Si riporta la gerarchia appena esposta:
Figura 4.10: Diagramma dell’architettura del Controller4.4. PROGETTAZIONE DEL CONTROLLER 23
4.4.3 FacebookSDK
L’applicazione web sviluppata doveva essere inserita all’interno del Canvas Frame di
Facebook e dunque necessitava di interfacciarsi con esso attraverso le API che espone.
Il problema nasce da come queste API cambino anche a distanza di pochi mesi. Per
questo si è pensato di creare una classe FacadeFacebookSDK che, sfruttando il Design
Pattern Facade, esponesse all’applicazione alcuni metodi necessari al suo funziona-
mento, nascondendo al suo interno le chiamate ai metodi effettivi delle Facebook API.
E stato garantito così un basso accoppiamento e un codice più pulito.
4.4.4 Middleware
Una novità introdotta in Laravel dalla versione 5.0 sono i middleware, un meccanismo
creato per il filtraggio delle richieste HTTP. Ad esempio vengono utilizzati per il con-
trollo dell’autenticazione dell’utente che, in caso non fosse correttamente autenticato,
verrebbe reindirizzato alla pagina di login. Questo meccanismo permette di eseguire
questo controllo alla richiesta di ogni pagina prima ancora di eseguire la corrispondente
funzione del controller e quindi di non eseguire il controllo direttamente nel codice di
quest’ultimo.
Nel caso specifico dell’applicazione è stato creato un middleware FacebookCheck che
controlla la corretta autenticazione dell’utente all’interno del social network. Facebook-
Check in caso di errore reindirizzerà l’utente all’interno del Canvas Frame di Facebook.
Infatti poiché l’applicazione è stata pensata per funzionare solamente all’interno del
Canvas Frame di Facebook, la mancata autenticazione indicherà una situazione di
errore o di accesso esterno dall’esterno del social network.
1 class AgeMiddleware {
2 public function handle ( $ request , Closure $ next )
3 {
4 if ( $ request - > input ( ' age ') < 2 0 )
5 {
6 return redirect ( ' home ') ;
7 }
8 return $ next ( $ request ) ;
9 }
10 }
11
12 class MainController extends Controller {
13
14 /* *
15 * MainController instance .
16 */
17 public function __construct ()
18 {
19 $ this - > middleware ( ' ageMiddleware ') ;
20 }
21 }
Codice 4.3: esempio di Middleware
Nell’esempio si può vedere come nella prima classe viene definito un middleware,
che nel caso in cui il parametro “age” fosse inferiore a 20, reindirizza la richiesta alla
pagina “home”, altrimenti permette alla richiesta di proseguire. Per associare questo24 CAPITOLO 4. PROGETTAZIONE
middleware al controller MainController basta richiamare all’interno del costruttore
di quest’ultimo il metodo middleware passando come unico parametro il nome del
middleware appena creato.
4.5 Progettazione delle View
Per la creazione delle viste, Laravel include out of the box Blade. Esso è un template
engine molto semplice ma anche molto potente, che permette la creazione di template
che ne estendono altri, così da rendere il codice più pulito, mantenibile e riutilizzabile.
Nonostante le sue svariate funzionalità, Blade non impedisce l’utilizzo di PHP vero e
proprio nel codice. Tutte le view vengono compilate e messe in cache per poi essere
ri-compilate in caso di modifiche, il che garantisce un overhead di Blade praticamen-
te prossimo allo zero. Tutti i file per essere riconosciuti da Blade devono avere un
estensione del tipo file.blade.php.
Nella figura 4.11 è possibile vedere la struttura dell’architettura generale delle view.
Package layout
Questo package raggruppa tutti i template responsabili dell’aspetto grafico, comuni a
tutte o più di una pagina del sito:
• main_layout.blade: file contenete la struttura base delle pagine dell’applicati-
vo come l’inclusione dei fogli di stile, script Javascript ed il layout della barra
superiore;
• top_bar.blade: template contenente il codice per la grafica della top bar del sito;
• friend_layout.blade: questo file viene utilizzato da results.blade per visua-
lizzare, sotto ai risultati dell’utente della lista appena compilata, gli esiti della
stessa di alcuni amici dell’utente stesso;
• other_lists.blade: come per il precedente template, viene utilizzato da results.blade
per proporre all’utente altre liste a cui sottoporsi;
• footer.blade: file contenente il layout della barra inferiore di ogni pagina.
Package list_drawing_up_views
In questo package sono racchiusi i template delle pagine riguardanti la compilazione di
una lista, cioè dunque l’atto dell’utente di selezione degli elementi in essa contenuti e
la conseguente visualizzazione del risultato ottenuto:
• drawing_up.blade: template della pagina di selezione degli elementi di una
determinata lista;
• results.blade: pagina di visualizzazione del risultato aggregato dopo la com-
pilazione di una lista (viene utilizzato questo template anche per visualizzare il
risultato di un amico);4.5. PROGETTAZIONE DELLE VIEW 25
Figura 4.11: Diagramma dell’architettura delle View26 CAPITOLO 4. PROGETTAZIONE
• details.blade: pagina che mostra in dettaglio gli elementi che l’utente ha
selezionato (viene utilizzato questo template anche per visualizzare il risultato
dettagliata di un amico);
• all_list _results.blade: template per mostrare tutte le liste a cui l’utente si
è sottoposto e il relativo risultato.
Package list_creation_views
La grafica della funzionalità di creazione e gestione delle liste è contenuta in questo
package così strutturato:
• manage.blade: template della pagina di gestione delle liste, e dunque di visualiz-
zazione dell’elenco delle liste, create dall’utente autenticato, con le relative stati-
stiche (nel caso di un utente con privilegi di amministratore, verranno visualizzate
tutte le liste presenti nella piattaforma).
• create.blade: pagina che offre all’utente una procedura di creazione di una
nuova lista;
• update.blade: permette all’utente autenticato la modifica di una lista creata
dallo stesso;
• show.blade: visualizza un’anteprima della lista selezionata;
• show_items.blade: pagina di visualizzazione degli elementi che compongono la
lista che l’utente sta visualizzando.
Infine, al di fuori dei package appena elencati, vi sono due classi template: una
index.blade che si occupa della visualizzazione della homepage dell’applicazione web,
visualizzando un insieme di liste da proporre all’utente, secondo una logica selezionabile
nella configurazione; la seconda facebook_authentication.blade contiene uno script
Javascript, responsabile della comparsa del pop-up di Facebook, con il quale l’utente
accetta l’invio delle proprie informazioni all’applicazione.
4.6 Diagrammi delle attività
I diagrammi delle attività illustrati di seguito, descrivono le interazioni tra l’utente ed
l’applicazione. Essi sono stati definiti durante le attività di progettazione dell’archi-
tettura, per mostrare che il prodotto integrasse tutte le funzionalità richieste.
4.6.1 Attività principale
Una volta aperta l’applicazione l’utente visualizza l’homepage dalla quale ha la possi-
bilità di:
• scegliere una lista e iniziare di conseguenza la sua compilazione;
• visualizzare tutti i propri risultati ottenuti da precedenti compilazioni;4.6. DIAGRAMMI DELLE ATTIVITÀ 27
Figura 4.12: Diagramma delle attività - Attività principale28 CAPITOLO 4. PROGETTAZIONE
• gestire le proprie liste;
• tornare alla homepage mentre sta visualizzando altre pagine.
4.6.2 Compilazione di una lista
Figura 4.13: Diagramma delle attività - Compilazione di una lista
Dopo che l’utente ha scelto di compilare una lista e cioè scegliere quali elementi
selezionare all’interno di essa può:
• visualizzare gli elementi in gruppi di 10 e selezionarne alcuni, tutti o nessuno;4.6. DIAGRAMMI DELLE ATTIVITÀ 29
• visualizzare il risultato sintetico (del tipo “Hai selezionato x elementi su y”) al
termine della compilazione;
• decidere ora se:
– selezionare un’altra lista a cui sottoporsi;
– condividere il risultato con un amico;
– visualizzare i propri risultati in maniera dettagliata (cioè quali elementi ha
appena selezionato);
– visualizzare il risultato aggregato e dettagliato di un amico che ha compilato
la medesima lista.30 CAPITOLO 4. PROGETTAZIONE
4.6.3 Gestione liste
Figura 4.14: Diagramma delle attività - Gestione liste
Una volta entrato nella gestione delle proprie liste, l’utente può:
• selezionare una lista e modificarla o, nel caso non avesse concluso la creazione
della stessa, riprendere l’operazione da dove aveva abbandonato;
• creare una nuova lista da pubblicare nella piattaforma.4.6. DIAGRAMMI DELLE ATTIVITÀ 31
4.6.4 Gestione risultati liste
Figura 4.15: Diagramma delle attività - Gestione risultati liste
Nella visualizzazione dei risultati di tutte le liste l’utente ha la possibilità di selezio-
nare una determinata lista, ovviamente tra quelle che ha già compilato, e visualizzarne
prima il risultato sintetico e successivamente quello dettagliato.32 CAPITOLO 4. PROGETTAZIONE
Capitolo 5
Implementazione e testing
In questo capitolo vengono descritte le attività di codifica dell’applicazione, a seguito
della terminazione della progettazione architetturale.
5.1 Strumenti
Per implementare questa applicazione web, era necessario scegliere quale IDE utilizzare
tra i tanti esistenti. In passato lo studente aveva utilizzato ad esempio NetBeans, poiché
uno degli IDE più completi tra quelli free, ma non era stato abbastanza soddisfacente.
L’attenzione è dunque ricaduta su PHPStorm, come consigliato dalla comunity di
Laravel, strumento questo specifico per i linguaggi PHP, HTML e Javascript. Consente
l’analisi del codice al volo, la prevenzioni degli errori, l’auto-completamento e dispone
di molte altre funzionalità interessanti. Unico punto a sfavore è che si tratta di un
software a pagamento, ma per fortuna è possibile ottenere una licenza free limitata per
gli studenti.
La versione utilizzata durante lo stage è PHPStorm 8.0.3.
Figura 5.1: logo di PHPStorm
5.2 Implementazione del backend
A seguito della progettazione si è passati all’implementazione vera e propria del bac-
kend, iniziando dall’integrazione con Facebook.
5.2.1 Autenticazione con Facebook
Il Canvas Frame di Facebook altro non è che un iframe all’interno del quale viene
visualizzata la propria applicazione. Esso però non si limita ad aprire la homepage del
sito, ma invia una richiesta HTTP POST contenente la Signed Request. Essa, senza
3334 CAPITOLO 5. IMPLEMENTAZIONE E TESTING
entrare troppo nel dettaglio, consiste in una stringa, nella quale sono codificate una
serie di informazioni per identificare l’utente attualmente autenticato, e un token che
identifica la sessione all’interno del browser. Sfruttando però le librerie PHP SDK non
è necessario conoscere in dettaglio il funzionamento della Signed Request, poichè queste
librerie mettono a disposizione già dei metodi per dialogare con Facebook.
Si riporta un esempio di funzione per la creazione della sessione sfruttando la Signed
Request inviata dal Canvas Frame:
1 public static function c r e a t e F a c e b o o k S e s s i o n F r o m C a n v a s () {
2 $ helper = new F a c e b o o k C a n va s L o g i n H e l pe r () ;
3 try {
4 $ facebookSession = $ helper - > getSession () ;
5 } catch ( Fa c e bo o k Re q u es t E xc e p ti o n $ ex ) {
6 // When Facebook returns an error
7 echo $ ex - > getMessage () ;
8 return false ;
9 } catch (\ Exception $ ex ) {
10 // When validation fails or other local issues
11 echo $ ex - > getMessage () ;
12 return false ;
13 }
14 if ( isset ( $ facebookSession ) ) {
15 // user is logged in
16 }
17 // Facebook Session is not valid
18 return false ;
19 }
Codice 5.1: funzione di recupero sessione dal Canvas
Questa funzione restituisce un oggetto Facebook Session, necessario poi per richieste
al social network, come ad esempio ottenere il profilo dell’utente o la lista dei suoi
amici. In caso di errore vengono sollevate delle eccezioni.
L’estratto di codice seguente invece, a partire dall’oggetto sessione ottenuto dalla
funzione soprastante, invia una richiesta al social network restituendo le informazioni
dell’utente autenticato:
1 if ( isset ( $ facebookSession ) ) {
2 $ requestU = new FacebookRequest (
3 $ facebookSession ,
4 ' GET ' ,
5 '/ me '
6 );
7 try {
8 $ response = $ requestU - > execute () ;
9 } catch ( F a c e b o o k A u t h o r i z a t i o n E x c e p t i o n $ ex ) {
10 Self :: $ fb_Session = null ;
11 echo $ ex - > getMessage () ;
12 return null ;
13 }
14 $ userInfo = $ response - > getGraphObject () ;
15 return $ userInfo ;
16 }
17 else
18 return null ;
Codice 5.2: estratto richiesta informazioni utente da Facebook5.2. IMPLEMENTAZIONE DEL BACKEND 35
Queste sono solo alcuni esempi di funzioni che sono state utilizzate per creare la clas-
se FacaceFacebookSDK, la quale espone una interfaccia al resto dell’applicazione che
permette di:
• creare la sessione Facebook a partire dalla Signed Request;
• controllare che la sessione sia ancora valida, che per questioni di sicurezza ha una
durata limitata);
• ottenere le informazioni le informazioni dell’utente restituendo un oggetto FacebookUser,
proprietario dell’applicazione;
• ottenere la lista degli amici dell’utente;
All’atto pratico ogni qual volta una pagina viene richiesta, il middleware
CheckFBAuthentication sfrutta i metodi esposti da FacaceFacebookSDK, per con-
trollare che l’autenticazione sia andata a buon fine e permette alla richiesta di essere
soddisfatta dal controller competente.
5.2.2 Model
Ogni model precedentemente progettato, per funzionare in Laravel, non necessita di al-
cun metodo al suo interno. Infatti Eloquent ORM rende disponibili moltissime funzioni
per operare con i dati contenuti nel database, dove ogni riga della tabella è rappresenta-
ta da un oggetto e ogni colonna da un attributo. È possibile per esempio con il metodo
all applicato sul model, ottenere una lista di oggetti che rappresentano i dati conte-
nuti nella tabella. Eloquent ORM permette però di definire dei Query Scope statici o
dinamici, per definire dei set comuni di condizioni, da poter riutilizzare successivamen-
te nell’applicazione. Ad esempio, per recuperare i risultati di una specifica lista degli
amici dell’utente autenticato, è stato definito il seguente Quesry Scope dinamico che,
data in input la lista degli ID degli amici e l’ID di una lista, restituisce una tabella
che associa utente amico e risultato.
1 public function scopeFriendResults ( $ query , $ friends , $ list_id ) {
2 return $ query - > whereIn ( ' facebook_id ' , $ friends )
3 -> join ( ' facebook_user_lists ' , ' user_id ' , '= ' , ' id ')
4 -> where ( ' list_id ' , '= ' , $ list_id )
5 -> orderBy ( ' result ' , ' desc ') ;
6 }
Codice 5.3: query scope per ottenere i sisultati degli amici di una lista specifica
Queste, insieme ad altre funzioni molto più banali, come per esempio controllare se
l’utente è amministratore o una lista è stata pubblicata, hanno permesso poi una più
agevole implementazione dei controller, evitando di inserire query all’interno di essi.
5.2.3 Controller
Il passo successivo allo sviluppo del model, è stata l’implementazione della gerarchia dei
controller precedentemente progettata. Ogni controller è stato reso accessibile creando
tre differenti rotte:36 CAPITOLO 5. IMPLEMENTAZIONE E TESTING
• /list_creation: per accedere alle pagine di creazione delle liste;
• /drawing_up: per accedere alle funzionalità di fruizione delle liste nell’applica-
zione web;
• /: rootpath per la homepage e le pagine dei risultati degli amici.
Dopodiché per ognuno dei controller, osservabili in figura 4.10, sono state codificate le
funzioni per rispondere alle possibili richieste provenienti dall’utente, attraverso l’inter-
faccia grafica. In particolare in MainController, troviamo, all’interno del costruttore
della classe, l’associazione al middleware FacebookCheck in modo che venga ereditato
da tutta la gerarchia di classi sottostante.
Ogni funzione implementata all’interno di un controller in Laravel deve avere la
seguente forma:
1 /* *
2 * Responds to requests to GET / show / 1
3 */
4 public function getShow ( $ id )
5 {
6 //
7 }
Codice 5.4: esempio di funzione di un controller
La funzione getShow() dell’esempio, viene eseguita quando l’applicazione riceve una
richiesta HTTP GET sulla URL /show, mentre la stessa funzione con parametri, ri-
spenderà alla medesima richiesta, arricchita dallo stesso numero di parametri separati
da uno “/”; Nell’esempio soprastante è presente un solo parametro id.
Si riporta ora una delle funzioni implementata all’interno del controller
ListCreationController:
1 /* *
2 * Display the specified list .
3 *
4 * @param int $ id
5 * @return Response
6 */
7 public function anyShow ( $ id ) {
8 $ user = $ this - > facadeFB - > getUser () ;
9 $ list = List :: find ( $ id ) ;
10 $ elements = $ list - > elements () -> get () ;
11 return view ( " list_creation_views . show " , [ ' user ' = > $ user , ' list '
= > $ list , ' elements ' = > $ elements ]) ;
12 }
Codice 5.5: funzione per visualizzare una specifica lista
Nel codice sopra, la funzione anyShow($id) permette di far visualizzare la lista con
numero identificativo (ID) specificato nella URL. Viene innanzitutto recuperato l’u-
tente autenticato attraverso la FacadeFacebookSDK (ogni controller ne possiede un
puntatore), viene poi recuperata la lista dal database, corrispondente all’ID specificato
e successivamente recuperati anche tutti i suoi elementi, con il metodo elements()
(implementato nel model List). Nell’ultima istruzione il metodo view (un cosiddet-
to helper di Laravel) crea la vista show, del package list_creation_views, con gli
opportuni parametri, che specificano l’utente, la lista e gli elementi da visualizzare.5.2. IMPLEMENTAZIONE DEL BACKEND 37
Ajax
Per garantire un’esperienza migliore all’utente nella fruizione dell’applicazione web,
sono state implementate alcune azioni di gestione delle liste, come ad esempio la can-
cellazione, fruttando Ajax. In Laravel l’utilizzo di Ajax è molto immediato, infatti la
firma delle funzioni in un controller non cambia, sarà il framework ad occuparsi di
tutto; unica differenza sta nel tipo di risposta data dalla funzione, che dovrà essere in
formato json invece di produrre una nuova pagina web.
1 /* *
2 * Ajax function example
3 *
4 * @param int $ id
5 * @return Response
6 */
7 public function ajaxRequest ( $ id ) {
8
9 // do something
10
11 return responce () -> json ([ ' state ' = > ' success ' ]) ;
12 }
Codice 5.6: funzione per visualizzare una specifica lista
Nel caso Javascript non funzionasse a dovere o fosse disattivato, renderebbe impos-
sibile eseguire le operazioni di gestione delle liste, rese disponibili tramite Ajax. Si
è dunque prevista nell’interfaccia Web e nei controller, la gestione delle sopracitate
funzionalità anche attraverso classiche richieste HTTP, permettendo così un degrado
elegante senza compromettere accessibilità e usabilità dell’applicazione.38 CAPITOLO 5. IMPLEMENTAZIONE E TESTING
5.3 Implementazione dell’interfaccia
La realizzazione delle interfacce dell’applicazione è avvenuta utilizzando Blade, il tem-
plate engine di Laravel. Il linguaggio utilizzato per la codifica delle pagine è HTML
5, supportato graficamente da una Bootstrap 3 e con fogli di stile scritti nello standard
CSS3.
Blade
La creazione di template in Blade è molto semplice e sfrutta una serie di keywords
messe a disposizione dal template engine. Un esempio di template base è il seguente:
1
2 < html >
3 < head >
4 < title > App Name - @yield ( ' title ')
5
6 < body >
7 @section ( ' sidebar ')
8 Master sidebar .
9 @endsection
10
11 < div class = " container " >
12 @yield ( ' content ')
13
14
15
Codice 5.7: esempio di template base in Blame
In questo modo è possibile definire l’intelaiatura base della pagine, la quale è facil-
mente estendibile per creare poi vere e proprie pagine, che dovranno solamente definire
il loro contenuto specifico. La keyword @section definisce una sezione con dei conte-
nuti specifici che potrà essere estesa o ridefinita, mentre la keyword @yield funge da
segnaposto per contenuti che verranno aggiunti successivamente (da pagine derivanti
da questa “base”).
Una possibile estensione del template base ad esempio può essere la seguente:
1 @extends ( ' layouts . master ')
2
3 @section ( ' sidebar ')
4 @parent
5 appended to the master sidebar
6 @stop
7
8 @section ( ' content ')
9 Page content .
10 @stop
Codice 5.8: possibile estensione del template base
Nell’esempio viene esteso il template prima indicato, al quale viene aggiunto del
contenuto alla sezione sidebar e definito il corpo della pagina finale.5.3. IMPLEMENTAZIONE DELL’INTERFACCIA 39
Javascript
Per lo sviluppo dell’applicativo è stato necessario un cospicuo utilizzo di script Java-
sript sviluppati appositamente, in particolare per rendere la paginazione client-side.
Inizialmente si sono cercate delle soluzioni prefabbricate, ma esse non rispondevano a
pieno alle esigenze richieste. Perciò si è deciso di sviluppare un plugin autonomamente
chiamato pagination.js.
Per implementare questo plugin si è scelto di sfruttare la tecnica dei prototipi per
mantenere il codice più pulito.
In Javascript ciascuna classe presenta al suo interno una proprietà, chiamata appun-
to prototype, che presenta un “meta oggetto”. Qualsiasi oggetto facente capo a questa
classe, sarà istanziato esattamente come una copia di questo prototipo. Modificando
questa meta classe, sarà possibile influenzare direttamente tutti i precedenti oggetti
creati a partire da questa classe, anche a runtime.
Dunque è possibile definire una classe con il solo costruttore che imposta gli attributi
della classe, e successivamente aggiungere al prototipo i metodi della stessa, rendendo
più leggibile e mantenibile il codice.
Si presenta ora un estratto dallo script pagination.js:
1 function Pagination ( perPage , form_control , back_action , validation_func ) {
2 this . itemPerPage = perPage ;
3 this . form_control = form_control ;
4 this . back_action = back_action ;
5 this . validation_func = validation_func ;
6 }
7
8 Pagination . prototype . _showPage = function ( i ) {
9 this . items . hide () ;
10 this . items . removeClass ( ' hidden ') ;
11 var startIndex = 0 ;
12 var endIndex = 0 ;
13 if ( this . activePage == 1 ) {
14 startIndex = 0 ;
15 endIndex = this . itemPerPage ;
16 }
17 else {
18 startIndex = this . itemPerPage * ( this . activePage - 1 ) ;
19 endIndex = this . itemPerPage * ( this . activePage ) ;
20 }
21 var showItems = this . items . slice ( startIndex , endIndex ) ;
22 showItems . fadeIn () ;
23 };
24 [...]
Codice 5.9: estratto di pagination.js
Nel codice sopra troviamo il costruttore della classe Pagination che riceve come
attributi: il numero di elementi per ogni pagina, un boleano che indica se attivare
la funzionalità di form, la funzione da eseguire con il pulsante back e la funzione di
validazione dei dati nel caso si tratti di un form. Questo script di paginazione infatti
permette di paginare semplici liste di elementi o anche dei form, entrambe funzionalità
ricercate per la realizzazione dell’applicazione.40 CAPITOLO 5. IMPLEMENTAZIONE E TESTING
Sotto il costruttore troviamo come, grazie al prototype, è possibile aggiungere il
metodo showPage (in questo caso metodo privato) alla classe Pagination.
L’utilizzo del suddetto plugin è molto semplice, basta istanziare un nuovo oggetto
Pagination passando al costruttore le configurazioni desiderate e utilizzare i metodi
createNav() e activatePage(); rispettivamente per creare il menù di paginazione e
attivare la prima pagina. Unici vincoli sono la presenza, nella pagina da paginare, di
un div con attributo id=item-container contenente gli elementi da paginare e un ul
con id=pagination che conterrà il menù creato dal plugin.
1 function goBack () {
2 $ ( '# list - info ') . toggleClass ( ' hidden ' , ' true ') ;
3 $ ( '# item - list ') . toggleClass ( ' hidden ' , ' false ') ;
4 }
5
6 var pag = new Pagination ( du_item_per_page , 1 , goBack ) ;
7 pag . createNav () ;
8 pag . activatePage ( 1 ) ;
Codice 5.10: utilizzo di pagination in drawing_up.js
5.3.1 Autenticazione
Non appena un nuovo utente tenti di utilizzare l’applicazione verrà mostrato il pop-
up in figura 5.2, con il quale si acconsente l’invio delle proprie informazioni ad essa.
In particolare verrà richiesto l’accesso al profilo pubblico, all’indirizzo email e alla
lista degli amici. L’utente può eventualmente negare l’accesso a queste due ultime,
compromettendo però la fruizione alla funzionalità di vedere i risultati degli amici che
hanno compilato le sue stesse liste.Puoi anche leggere
