Una descrizione di cosa andava implementato:
Parte relativa agli utenti
-
Registrazione
Gli utenti devono registrarsi alla rete sociale grazie ad un opportuno modulo di registrazione. Si dovranno richiedere informazioni quali: nome*, cognome*, e-mail*, password*, data di nascita, luogo di nascita*, titolo di studio, hobby, avatar ecc. Potete decidere di richiedere anche un nickname da usare come username dell'utente oppure usare il suo indirizzo e-mail.
Nota: le informazioni con * sono obbligatorie.
Controllo dell'input: usate le espressioni regolari o altre tecniche per verificare la correttezza sintattica dell'input. In alcuni casi si può anche usare Ajax come abbiamo visto a lezione.
Ogni utente potrà decidere se rendere visibili le proprie informazioni a tutti gli altri utenti, solo ai suoi amici, a nessuno. Nome e cognome non possono essere nascosti. -
Login/Logout
Si devono realizzare le funzioni di Login/Logout gestendole in modo opportuno mediante uso delle variabili di sessione.
Nota: nella vita reale le credenziali per l'autenticazione non devono essere passate in chiaro. -
Modifica del profilo
I dati richiesti al momento della registrazione possono essere modificati in qualunque momento grazie alla funzione di modifica del profilo. -
Amici (Friends)
Dopo il login, un utente entra in una pagina dove il sistema gli propone un paio di altri utenti (al massimo 3) che potrebbero essere suoi amici. La relazione di amicizia viene calcolata considerando il luogo di nascita (che è un dato obbligatorio, anche se può essere nascosto agli altri utenti del sistema). Se ci sono più di 3 amici potenziali, il sistema ogni volta deve selezionarne 3 a caso. Se non esistono amici potenziali, il sistema dovrà restituire un messaggio opportuno.
Nota: non devono essere visualizzati quegli utenti che sono già in relazione di amicizia con l'utente appena autenticato. -
Vicini (Neighbours)
Dopo il login, un utente può richiedere di visualizzare l'elenco dei suoi vicini premendo un link o un pulsante opportuno. Per vicino si intende un altro utente registrato al sistema che ha un hobby in comune con l'utente appena autenticato. La relazione di vicinanza viene quindi calcolata considerando gli hobby. Se non esistono vicini potenziali, il sistema dovrà restituire un messaggio opportuno. Nel caso in cui l'utente non abbia specificato i propri hobby al momento della registrazione, il sistema dovrà restituire un messaggio opportuno e invitare l'utente ad aggiornare il suo profilo se vuole usare questa funzione.
Nota: non devono essere visualizzati quegli utenti che sono già in relazione di amicizia con l'utente appena autenticato. -
Altri utenti (Others)
Un motore di ricerca interno deve permettere la ricerca di altri utenti. I criteri da impostare per la ricerca devono essere definiti durante la fase di progettazione dell'applicazione. Qui potete usare Ajax per l'autocompletamento delle stringhe nella ricerca. Nel risultato della ricerca devono essere ben distinti gli utenti già in relazione di amicizia marcandoli in modo evidente. -
Inoltrare una richiesta di amicizia
Dopo il login, un utente A può inviare una richiesta di amicizia ad altri utenti B (Friends, Neighbours, Others). Questa richiesta verrà visualizzata nella pagina di ingresso al sistema dell'utente B che ha ricevuto la richiesta (e anche notificata via e-mail). -
Accettare una richiesta di amicizia
Dopo il login, un utente B con richieste di amicizia pendenti le vedrà visualizzate nella sua pagina di accesso alla rete sociale e dovrà decidere se accettarle oppure no.
In entrambi i casi, all'utente A che ha fatto la richiesta di amicizia dovrà essere notificata la scelta dell'utente B. -
Grafo degli amici
Dopo il login, un utente può richiedere la visualizzazione del grafo delle sue amicizie. Nel grafo delle amicizie gli utenti sono i nodi e gli archi rappresentano la relazione di amicizia tra gli utenti. Si tratta di un grafo non orientato poiché se A è amico di B, anche B è amico di A (almeno si spera!).
Il grafo deve essere costruito a partire dal nodo che rappresenta l'utente stesso e poi si devono calcolare (1) i suoi amici (2) gli amici dei suoi amici (3) ecc. fino a quando non si potranno più aggiungere nuovi nodi/archi (cioè dovete calcolare la componente fortemente connessa del grafo a partire dal nodo che rappresenta l'utente).
Il grafo deve essere visualizzato all'interno del browser. Per fare questo si usa neato che, dato un grafo descritto mediante il linguaggio DOT, creano un file SVG che descrive i nodi e gli archi del grafo. Il browser è in grado di visualizzare i file SVG. Sono accettate anche altre soluzioni che non usano gli script forniti sul server.
Per maggiori informazioni potete anche vedere http://www.graphviz.org/.
Parte relativa all'amministratore
L'amministratore è un utente speciale che può bannare gli utenti del sistema perché non rispettano le regole di comportamento della rete sociale.
Una volta autenticato l'amministratore dovrà vedere un link che gli permette di visualizzare l'elenco degli utenti registrati. L'amministratore può anche usare il motore di ricerca interna per cercare un particolare utente.
Una volta trovato l'utente, l'amministratore potrà bannarlo oppure cancellarlo in modo definitivo dal sistema. Un utente bannato riceverà un messaggio automatico di alert da parte dell'amministratore. Dopo 5 giorni un utente bannato torna attivo (automaticamente) e quindi può accedere nuovamente al sistema.
Se, invece, l'amministratore decide di cancellare in modo permamente un utente dalla rete sociale, questa informazione va propagata nelle relazioni di amicizia degli altri utenti del sistema. Gli utenti cancellati non possono comparire nel grafo degli amici (quelli bannati sì).
Requisiti da rispettare
- Dovete fare uso dei fogli di stile CSS per definire il look & feel dell'interfaccia.
- Dovete scrivere le parti comuni a tutte le pagine in file a parte che vengono condivisi da tutte le pagine del sito in modo da poter effettuare eventuali modifiche una sola volta per l'intero sito.
- Dovete dimostrare di conoscere JavaScript che può essere usato per validazione dell'input lato client, effetti speciali tipo il roll over delle immagini, apertura di nuove finestre (solo se utili per il sito), ...
- Dovete dimostrare di conoscere PHP ed è obbligatorio appoggiarsi ad un database in MySQL. L'accesso al database dovrà avvenire usando le librerie offerte da MDB2.
- Dovete provare ad usare Ajax.
- Le pagine del prototipo devono rispettare i requisiti di accessibilità visti a lezione e devono essere validate con il validatore del W3C, usando il DOCTYPE:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Nota. Nel progetto dovete rispettare almeno i seguenti requisiti di accessibilità
- Non è consentito l'uso dei frame
- Si devono evitare oggetti e scritte lampeggianti
- Si devono usare i fogli di stile
- La presentazione e i contenuti testuali di una pagina devono potersi adattare all'interfaccia senza sovrapposizione degli oggetti presenti
- Le pagine dovranno essere parzialmente utilizzabili quando gli script sono disabilitati o non supportati
- La destinazione di ogni collegamento ipertestuale deve essere espressa con testi significativi
- I collegamenti principali presenti in una pagina devono essere selezionabili e attivabili tramite comandi da tastiera
Ed ora, i file:
- Documentazione, leggetela!
- Database mySQL, acceduto con MDB2, senza utilizzare transazioni, per la connessione editare db.php secondo le proprie necessità
- File del progetto, le parti di javascript e ajax si trovano in header_fuori.php
- Sarebbe opportuno rinominare i .tmp contenti codice php in .php, per sicurezza
- Il sistema è stato testato su LAMP e XAMPP con browser Firefox, Iceweasel ed Internet Explorer (7 e 8). Opera presenta problemi grafici noti.
No comments:
Post a Comment
With great power comes great responsibility