Impl: Livello application

[GoogleCodeExporter]

Descrizione dettagliata del task
Implementazione degli oggetti control progettati in fase di Object Design.
Tenete sempre in mente che nella Issue42 e nella Issue43 ci sono modifiche alle 
funzionalità da implementare.
Se si rivelano necessari nuovi oggetti control, è consentito aggiungerli con 
il vincolo che:
-Siano documentati i loro metodi
-Rispettino i vincoli di implementazione dei control che sono stati sviluppati 
in precedenza, nelle linee guida

Se gli oggetti control da voi implementati richiedono metodi non esistenti 
delle classi storage:
-Aggiungere il metodo nella classe storage utilizzata dal control
-Documentare il metodo tramite Javadoc
-Inserire un commento di //TODO nel corpo del metodo
-Avvisare lo sviluppatore di quella classe storage, consentendogli di 
implementare il nuovo metodo.

Gli oggetti control dovranno essere testati opportunamente con JUnit.

Persone coinvolte
Gianfranco Bottiglieri
Antonio Cesarano
Marco Parisi

Artefatti previsti in output
Oggetti control implementati e testati

Scadenza
29-11-2012

Original issue reported on code.google.com by funfor...@gmail.com on 25 Nov 2012 at 3:41

[GoogleCodeExporter]

Vorrei che ci faceste sapere il prima possibile come vi sarete divisi il lavoro 
di implementazione degli oggetti control, grazie.

Original comment by funfor...@gmail.com on 25 Nov 2012 at 3:42

[GoogleCodeExporter]

Vorrei anche farvi notare che vi sono alcune nuove funzionalità che richiedono 
dei control associati, come la gestione delle notifiche da visualizzare nel 
sistema. 
Detto questo, vorrei che stilaste quì una lista dei control la cui priorità 
di implementazione è più alta e che partiste dall'implementare quelli.
Fateci sapere anche come ve li dividerete.

Original comment by funfor...@gmail.com on 25 Nov 2012 at 3:45

[GoogleCodeExporter]

Di seguito le priorità delle gestioni per l'implementazione dei control.
Ovviamente l'implementazione deve partire da quelle con priorità ALTA.

Priorità Gestioni ACCESSI:
Gestione Dati Bando (ALTA)
Gestione Dati Personali (ALTA)
Gestione iscritti - ALTA tranne:
UC_A_68_Conferma assegnazione classe (intesa quella con notifica interna al 
sistema, MEDIA)
UC_A_69_Rifiuta assegnazione classe (intesa quella con notifica intesa quella 
interna al sistema, MEDIA) 

Gestione Notifiche (Media)
Gestione Personale (Media)
Ricerca (Media)

Gestione MANAGEMENT:
Gestione Tirocinanti (bassa)
Gestione Pagamenti (Media)
Gestione Piani Pasto (Media)
Gestione Orari (Media)

Gestione HOME:
Gestione Registro (ALTA)
Gestione Eventi (Media)
Gestione Questionari (Media)

Aggiungo inoltre Elisa a questo task, dovrà dividersi i control.

Scadenza
28-11 ore 23

Original comment by funfor...@gmail.com on 26 Nov 2012 at 3:49

• Added labels: Scadenza-28-11-2012
• Removed labels: Scadenza-29-11-2012

[GoogleCodeExporter]

Vi vorrei far notare che l'interfaccia di ControlLogin è sbagliata: non potrà 
mai prendere in input un Utente, voi volete verificare che username e password 
in input corrispondano ad un utente, non il contrario!

Original comment by funfor...@gmail.com on 26 Nov 2012 at 5:59

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Vorrei inoltre sollecitare l'urgenza di fornire una documentazione javadoc ai 
metodi, PRIMA che li implementiate, in modo che i ragazzi che stanno 
realizzando presentation possano effettuare degli stub efficaci comprendendo i 
metodi.

Original comment by funfor...@gmail.com on 26 Nov 2012 at 8:10

[GoogleCodeExporter]

Come Linda faceva inoltre notare, usare dei tipi di ritorno booleani 
(true/false) per le operazioni dei control è sbagliato: se i risultati possono 
essere molteplici (diverse condizioni di errore che mostrano diverse interfacce 
a seconda dell'errore) i control dovranno restituire nei metodi un valore che 
consenta di dare il boundary giusto. Un modo può essere quello di restituire 
una stringa in caso di errore..
Un altro meccanismo può essere quello di scrivere delle eccezioni del tipo 
"CodiceFiscalePresenteException" da lanciare in casi del tipo di inserimenti di 
codici fiscali già presenti. 
I control avranno la throws nel metodo di inserimento (in questo caso di un 
genitore, ad esempio), e la servlet farà try-catch sull'eccezione, invocando 
il boundary associato di errore con il messaggio del codice fiscale già 
presente.

Original comment by funfor...@gmail.com on 26 Nov 2012 at 9:33

[GoogleCodeExporter]

Ma � stata proprio lei a suggerire il valore booleano xD

Original comment by cesarano...@gmail.com on 26 Nov 2012 at 9:35

[GoogleCodeExporter]

Io e quando? XD

Original comment by hilin...@gmail.com on 26 Nov 2012 at 9:45

[GoogleCodeExporter]

Ma comunque il bool è sensato nell'odd e in molti metodi, in altri meno se ci 
sono degli errori come lo fate a dire con un bool? :D

Original comment by hilin...@gmail.com on 26 Nov 2012 at 9:46

[GoogleCodeExporter]

ah scusa, era giulio XD Issue 32

Original comment by cesarano...@gmail.com on 26 Nov 2012 at 9:49

[GoogleCodeExporter]

Comunque lo avreste scoperto implementando

Original comment by hilin...@gmail.com on 26 Nov 2012 at 9:52

[GoogleCodeExporter]

Sì, confermo che ero io. Io però ho detto che l'uso delle eccezioni non è 
opportuno, ed è meglio usare i valori di ritorno, magari un boolean. Non ho 
detto che tutto può essere un boolean.

L'ho ribadito poi nella issue 32, perché inizialmente i metodi erano proprio 
void...

Original comment by blunotte...@gmail.com on 26 Nov 2012 at 9:56

[GoogleCodeExporter]

Ad ogni modo, ci sono due scuole di pensiero.
La prima, più fedele ai progettisti Java, ritiene che le eccezioni vadano 
usate per gestire errori di sistema e di programmazione, mentre il controllo 
degli input deve essere effettuato tramite istruzioni "normali". Questo anche 
perché le eccezioni in Java introducono un rallentamento (piccolo, ma 
misurabile).

La seconda, più aderente all'ingegneria del software, vorrebbe le eccezioni 
utilizzate anche per la gestione degli errori di input utente, perché, in 
questo modo, il controllo delle eccezioni viene separato dal flusso normale.

Original comment by blunotte...@gmail.com on 26 Nov 2012 at 10:06

[GoogleCodeExporter]

Allora questa divisione?
Chi è responsabile dei control di quale package?
Ragazzi tra poco scade il termine per l'implementazione e quà ancora dovete 
dividervi i control!
Queste classi devono essere anche testate oltre ad essere implementate quindi.. 
forzaaaa!

Original comment by funfor...@gmail.com on 27 Nov 2012 at 1:20

[GoogleCodeExporter]

io mi occupo della gestion del Bando e Marco Parisi del Login

Original comment by gianfranco.b.d on 27 Nov 2012 at 2:01

[GoogleCodeExporter]

Qui spiego come usare le classi atsilo.storage dalle classi atsilo.application.

//Come prima cosa, bisogna creare un'istanza di database e aprire una 
connessione
Database db = new Database();
if (!db.apriConnessione()) {
    /*
     * Connessione fallita
     * Bisogna restituire un errore all'utente
     */
}

//Quindi, si possono creare tutti i gestori di tabelle necessari
try {
    DBAccount dbAccount = new DBAccount(db);
    DBGenitore dbGenitore = new DBGenitore(db);

    /*
     * Qui si possono fare tutte le operazioni necessarie
     * sui gestori di tabelle.
     */
    return xxx;

} finally {
    /*
     * Alla fine dell'interazione, prima di uscire dal metodo,
     * bisogna chiudere la connessione.
     */
    db.chiudiConnessione();
}

By Giulio Franco

Original comment by marco.parisi90 on 27 Nov 2012 at 2:49

[GoogleCodeExporter]

Registro per adesso, appena termino comincio subito con un altro

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 3:20

[GoogleCodeExporter]

ok, io mi occupo di: gestioni dati personali e gestione iscritti

Original comment by elisa.de...@gmail.com on 27 Nov 2012 at 3:31

[GoogleCodeExporter]

Quando decidete che vi occupate di una classe, mettete il vostro nome nel campo 
autore del commento iniziale del file, che, vi ricordo, deve avere il formato 
descritto nel file header.txt ( 
http://code.google.com/p/at-silo/source/browse/trunk/Impl/header.txt ) e 
riportato di seguito:
/*
 *-----------------------------------------------------------------
 * This file is licensed under GPL 3.0:
 * http://www.gnu.org/licenses/gpl-3.0.html
 *-----------------------------------------------------------------
 * FILE: NomeFile
 *-----------------------------------------------------------------
 * PROGETTO: Atsilo
 *-----------------------------------------------------------------
 * OWNER
 * nome autore, data creazione
 * REVISION
 * nome revisore, data revisione
 *-----------------------------------------------------------------
 */

Original comment by blunotte...@gmail.com on 27 Nov 2012 at 3:37

[GoogleCodeExporter]

ho aggiunto il package atsilo.exception che conterr� tutte le eccezioni
lanciate dai control

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 4:12

[GoogleCodeExporter]

ho aggiunto l'eccezione DBConnectionException che deve essere lanciata nel
caso in cui la connessione al db non riesca. usiamo questa cos� non creiamo
diverse eccezioni che fanno la stessa cosa

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 4:19

[GoogleCodeExporter]

Le eccezioni che state creando dovrebbero avere una gerarchia comune. Se non 
ricordo male, estendendo java.lang.Exception si creano eccezioni gestite. 
Giusto?
Quindi, potreste creare una atsilo.exceptions.AtsiloException, e creare una 
gerarchia di eccezioni a partire da quella.

Original comment by blunotte...@gmail.com on 27 Nov 2012 at 4:35

[GoogleCodeExporter]

se estendiamo direttamente Exception?

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 4:36

[GoogleCodeExporter]

inoltre se non usiamo eccezioni che estendono RuntimeException, nella firma
del metodo si deve inserire la "throws"

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 4:38

[GoogleCodeExporter]

Appunto. Voi DOVETE mettere la throws, perché chi usa quelle classi deve 
sapere che una eccezione può essere lanciata, e DEVE essere costretto a 
gestirla, sennò viene stampata la stack trace all'utente. E questo, come il 
buon Parente insegna, non si deve fare.

Il fatto di usare un parente comune serve perché potreste voler gestire tutte 
le eccezioni di Atsilo in un modo, e le altre eccezioni in un altro modo. 
Facilita la gestione, niente di più. Se non pensate di averne bisogno, potete 
estendere direttamente Exception, ma se poi volete modificare dovete cambiare a 
mano tutte le eccezioni che avete creato.

Original comment by blunotte...@gmail.com on 27 Nov 2012 at 4:50

[GoogleCodeExporter]

Ci terrei a precisare che tutti i control a priorità ALTA dipendono da 
ControlLogin. Quindi, anche questo eredita la priorità ALTA.

Original comment by blunotte...@gmail.com on 27 Nov 2012 at 4:51

[GoogleCodeExporter]

che significa che i control dipendono da quello del login?

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 4:52

[GoogleCodeExporter]

che se non fai il login non vai da nessuna parte. Quindi, il login deve essere 
implementato...

Original comment by blunotte...@gmail.com on 27 Nov 2012 at 4:55

[GoogleCodeExporter]

passo a gestione evento

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 5:34

[GoogleCodeExporter]

Antonio: sei sicuro che non dovresti usare
if(!db.apriConnessione()) 

con la negazione (!)? Come lo leggo io secondo me tira eccezione in maniera 
matematica.

Original comment by funfor...@gmail.com on 27 Nov 2012 at 8:56

[GoogleCodeExporter]

@ Marco Parisi: DBAccount non credo sia giusto metterla come variabile di 
istanza del control. Credo sia il caso di istanziare un nuovo DBAccount ogni 
metodo che implementi.
Inoltre, apertura e chisura della connessione in ogni metodo che implementerai 
dovrà seguire lo schema try - catch - finally spiegato quì: 
https://groups.google.com/forum/?fromgroups=#!category-topic/at-silo/VGXB9Mp8tEc

Original comment by funfor...@gmail.com on 27 Nov 2012 at 9:01

[GoogleCodeExporter]

Confermo il Comment 32 di Alfonso. Usare le variabili di istanza in classi 
thread-safe (come devono essere i Control) richiederebbe concetti di 
programmazione concorrente che non avete.

Original comment by blunotte...@gmail.com on 27 Nov 2012 at 9:09

[GoogleCodeExporter]

� stato un errore di battitura e incollato, � logico che sia come dici tu
alfobso, grazie

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 9:24

[GoogleCodeExporter]

per il resto, visto ke hai dato un'occhiata, come ti sembrano?

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 9:43

[GoogleCodeExporter]

Mi sembrano "troppo semplici".
Sei sicuro che ad esempio l'inserimento di un evento come funzionalità debba 
solamente inserire l'evento nella base dati? Non deve gestire 
modifiche/inserimenti di altre entità o chiamare altri control per invocare 
altre operazioni? (Te lo dico non perchè so che deve essere fatto, solo temo 
ci stiamo dimenticando qualcosa).

Original comment by funfor...@gmail.com on 27 Nov 2012 at 9:48

[GoogleCodeExporter]

secondo me dovrebbe notificare i partecipanti dell'invito, ma la parte
delle notifiche ancora non � definita decentemente...

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 10:23

[GoogleCodeExporter]

Il control delle email è l'unico che è decentemente implementato XD
Se invece parli solo della notifica interna al sistema.. quella ha una 
priorità di implementazione più bassa quindi per ora non si fa.

Original comment by funfor...@gmail.com on 27 Nov 2012 at 10:24

[GoogleCodeExporter]

No alfonso evento è abbastanza easy .
Non ci sono neanche errori da gestire, è semplicemente l'inserimento di dati 
decisi dall'utente... se gestiamo le notifiche allora sarà compito del control 
notifiche vedere quando si sta verificando un evento...

Original comment by hilin...@gmail.com on 27 Nov 2012 at 10:26

[GoogleCodeExporter]

x� secondo me ci sta che quando si aggiungono i partecipanti viene inviata
una mail a tutti :-)

Original comment by cesarano...@gmail.com on 27 Nov 2012 at 10:28

[GoogleCodeExporter]

Ok, va bene allora. Per le notifiche interne al sistema si può attendere nel 
caso venga implementato. :)

Original comment by funfor...@gmail.com on 27 Nov 2012 at 10:28

[GoogleCodeExporter]

in db bando le date di inizio sono delle stringhe…. la domanda è non 
dovrebbero essere date?????

ma modifcando i valori in DBBando  si modificano in automatico anche nel 
database??? 

Original comment by gianfranco.b.d on 28 Nov 2012 at 2:40

[GoogleCodeExporter]

In SQL il tipo DATE ha il formato 2012-11-28.
Se ci scrivi una stringa dentro va bene, e penso che vada bene pure che leggi 
una stringa. Se poi volete usare il tipo java Date per me va bene :)

Original comment by funfor...@gmail.com on 28 Nov 2012 at 3:36

[GoogleCodeExporter]

Mentre attendo il controllo di controllogin.. inizio a implementare anche 
controlOrario

Original comment by marco.parisi90 on 30 Nov 2012 at 10:50

[GoogleCodeExporter]

finito gestione bando e ora passo a pagamenti
ps: in gestione bando non ho usato stub perchè era gia stato implementato in 
storage

Original comment by gianfranco.b.d on 30 Nov 2012 at 12:12

[GoogleCodeExporter]

State realizzando le classi JUnit,vero ?

Original comment by funfor...@gmail.com on 30 Nov 2012 at 3:01

[GoogleCodeExporter]

Marco: cosa intendi per "attendo il controllo di control login?" Le tue classi 
le devi testare tu con junit :)

Original comment by funfor...@gmail.com on 1 Dec 2012 at 2:02

[GoogleCodeExporter]

mi sono espresso male dovevo far vedere il control login a giulio e nel 
frattempo che avevo un paio d'ore iniziavo un'altro control xD

Original comment by marco.parisi90 on 1 Dec 2012 at 2:15

[GoogleCodeExporter]

mi sono espresso male dovevo far vedere il control login a giulio e nel 
frattempo che avevo un paio d'ore iniziavo un'altro control xD

Original comment by marco.parisi90 on 1 Dec 2012 at 2:15

[GoogleCodeExporter]

Ho un problema con la gestione dei bandi. Sviluppando l'interfaccia grafica ho 
notato che i dati non coincidono con quelli presenti nel database 
Per la precisione mancano :
-Data inizio presentazione rinuncia
-Data fine presentazione rinuncia
-Data fine rinuncia
-Posti disponibili

Quindi andrebbe modificato anche lo storage, l'application e l'entity bando.
(Probabilmente ci vuole anche un campo per salvare il path del file che 
carichiamo nella fase di "caricamento bando").

Original comment by lucar...@hotmail.it on 4 Dec 2012 at 2:58