Menu
▾
▴
lugman-java
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
(21) |
Nov
|
Dec
(1) |
|---|
|
From: Fabrizio Zacche' <za...@di...> - 2002-05-13 18:21:23
|
> Un riassunto degli strumenti che utilizzeremo: > > > - JDK 1.3.x (troppo presto per l'1.4). > > - CVS > > Per mantenere varie revisioni del codice e rimanere sincronizzati. L'archivio > si trova su Sourceforge. > > - Jakarta Ant 1.4.x > > E' un tool analogo a Make, solo che =E8 scritto in Java ed =E8 facilmen= te > estendibile. Permette di fare script che automatizzano le operazioni su= l cvs, > la compilazione, i test, l'impacchettamento in jar o war, il deploy sul web > server... > > - Jakarta Log4j 1.1.x > > Da usare al posto dell'orribile System.out.println per fare il debug de= l > codice ;) e per tenere un log di quello che accade. > > - Jakarta Tomcat 4.x (o 3.x ?) > > Web Server. > > - Jakarta Torque 3.0-b1 (da testare) > > Per creare Oggetti persistenti. > > - Database: > > MySQL 3.23.x (MAX per avere supporto transazioni) o PostgreSQL 7.2.x > > - NetBeans 3.3.1 > > Il miglior IDE open source per Java (ehm... ne esistono altri? ;) > Rende trasparenti le operazioni su CVS. > Zak far=E0 le JSP usando Struts, io e Simone le classi che fanno il lav= oro > sporco. Tutto OK. Circa il database, ho fatto qualche integrazione che vi propongo (tento d= i allegare un file postscript col modello, vediamo se vi arriva). Per essere sicuro che sia comprensibile a tutti, i riquadri rappresentano= le tabelle ed elencano al loro interno i campi; quello definito come chiave primaria (PK) si trova sopra la riga orizzontale nera. Le linee rappresentano le relazioni tra le tabelle e sono responsabili della prese= nza delle foreign key (FK) necessarie per implementare concretamente la relazione. Il pallino nero si trova sulla tabella dal lato "molti" della relazione uno-a-molti, mentre se =E8 presente un rombo bianco significa che la fore= ign key relativa alla relazione pu=F2 essere NULL (nel nostro caso, pu=F2 esi= stere un evento non associato ad un utente). Quello che ancora aggiungerei =E8 username e password per gli Users, se vogliamo che i singoli soci possano venire in sede e consultare da se il sistema. Fatemi sapere cosa ne pensate. Nel frattempo butto gi=F9 un prototipo di = sito in struts e ve lo mando per incominciare a ragionare sull'interfaccia con= le classi data-aware. -- Fabrizio Zacch=E9 aka Zack Mandrake Users Club Member |
|
From: Davide S. <lg-...@lu...> - 2002-04-26 13:48:06
|
Un riassunto degli strumenti che utilizzeremo:
- JDK 1.3.x (troppo presto per l'1.4).
- CVS
Per mantenere varie revisioni del codice e rimanere sincronizzati. L'archivio
si trova su Sourceforge.
- Jakarta Ant 1.4.x
E' un tool analogo a Make, solo che è scritto in Java ed è facilmente
estendibile. Permette di fare script che automatizzano le operazioni sul cvs,
la compilazione, i test, l'impacchettamento in jar o war, il deploy sul web
server...
- Jakarta Log4j 1.1.x
Da usare al posto dell'orribile System.out.println per fare il debug del
codice ;) e per tenere un log di quello che accade.
- Jakarta Tomcat 4.x (o 3.x ?)
Web Server.
- Jakarta Torque 3.0-b1 (da testare)
Per creare Oggetti persistenti.
- Database:
MySQL 3.23.x (MAX per avere supporto transazioni) o PostgreSQL 7.2.x
- NetBeans 3.3.1
Il miglior IDE open source per Java (ehm... ne esistono altri? ;)
Rende trasparenti le operazioni su CVS.
Zak farà le JSP usando Struts, io e Simone le classi che fanno il lavoro
sporco.
Per quanto riguarda il database, prima della creazione della mailing list,
avevamo buttato giù una struttura tipo questa:
-- USER:
ID
NAME
SURNAME
EMAIL
CITY
USER_TYPE_ID (tipo di socio: ordinario, benemerito, fondatore).
-- USER_EVENT_MAP:
ID
ID_USER
ID_EVENT
-- EVENT:
ID (id dell'evento)
SUBMIT_DATE (data in cui l'evento è stato inserito)
EVENT_TYPE_ID (tipo di evento)
APPLY_DATE (data in cui si è verificato o si verificherà l'evento)
-- EVENT_TYPE:
ID
DESCRIPTION (pensavo a questi tipi:
- 'inizio iscrizione':
l'utente si è iscritto, dopo questo evento deve esserci un evento
'iscrizione annuale socio ordinario', 'iscrizione annuale socio
benemerito', o 'iscrizione annuale socio fondatore'.
- 'fine iscrizione'
l'utente non è più iscritto
- 'espulsione'
l'utente è stato espulso, dopo questo evento (APPLY DATE) ci sarà un
evento 'fine iscrizione'
- 'iscrizione scaduta'
l'utente non ha rinnovato, dopo questo evento (APPLY DATE) ci sarà un
evento 'fine iscrizione'
- 'iscrizione annuale ...'
l'utente si è iscritto per un anno, viene creato/modificato l'evento
'iscrizione scaduta' (con APPLY DATE tra un anno...)
Può andare?
Prossimo passo dovrebbe essere quello di definire un'API per le librerie di
backend che verranno utilizzate dalle JSP, a grandi linee si potrebbero
dividere in 3:
1) Oggetti persistenti (User, Event...)
2) Report (vari report: tutti gli iscritti, iscritti che hanno scadenza tra
n giorni, persone che non hanno rinnovato...)
3) Search
Una volta definite le interfaccie da usare possiamo finalmente iniziare a
sviluppare... ;)
Ciao,
--
Davide
|
|
From: Davide S. <lg-...@lu...> - 2002-04-10 18:57:23
|
On Monday 08 April 2002 22:01, you wrote: > Pro: > - E' lo standard di domani Sembra di sì... > - Genera la struttura del database in funzione agli oggetti da rendere > persistenti Bello. Questa è una cosa da sperimentare. Se ho una classe A che utilizza al suo interno una classe B, JDO crea due tabelle e poi quando voglio ripescare i dati mi fa la Join? E se ho una classe C che estende A, mi crea un'altra tabella o mi modifica la tabella dedicata ad A? > Contro: > - Non esistono ancora implementazioni OpenSource Ahi ahi... > - Nell'implementazione che ho scelto (RexIP, vedi dopo) viene usata una > tecnica di modifica dei file .class (quindi interviene dopo la compilazione > dei sorgenti) per aggiungere in modo trasparente il codice necessario alla > persistenza (!!) Ugh! In questo modo se c'è un bug c'è da impazzire... Ti tocca decompilare il tuo stesso codice! Preferirei avere un tool che mi legge il class e poi mi spara fuori il codice necessario.. Se lo gestisci con un 'ide non è una rottura e almeno sai cosa c'è dentro le tue classi. Altre implementazioni che metodi usano? > Tutto sommato JDO è affascinante e credo meriti in ogni caso di essere > conosciuto, anche solo per poterlo confrontare a soluzioni che usano JDBC o > J2EE. Yes. Ma forse al momento è una tecnologia un pò troppo 'on the edge'. > Restano i (pochi) prodotti commerciali. > Tra questi ho scelto JDO di RexIP (http://www.rexip.com), perché è > utilizzabile in una versione Developer che non è limitata a tempo né a > funzionalità ma solo a "scalabilità": il pool di connessioni lavora solo > con una connessione (in pratica il pool non è attivo ma per noi questo è > meno di un problema). Ma non gli si può far usare il pool di connessioni dell'application server? > Detto questo, potremo procedere così: se questa settimana avete tempo di > valutare JDO e siete d'accordo di usarla, potremo trovarci venerdì 12 in > sede per stabilire come partizionare il lavoro e chi farà cosa. > Altrimenti rimarrà comunque valida l'occasione dell'assemblea. Dal mio punto di vista non mi sembra il caso di utilizzare software non open source, considerando che è un programma per il Lugman ;) Anche perchè le alternative ci sono... Cmq con o senza JDO io vorrei proporre l'adozione di alcuni pattern suggeriti dalla Sun e che ci possono permettere di switchare da un metodo di persistenza all'altro: JDBC, JDO, XML, file binario, and last but not least schede perforate. (Zak a te l'ho già detto ma lo riposto qua). L'elenco di tutti i pattern è qua http://developer.java.sun.com/developer/restricted/patterns/J2EEPatternsAtAGl ance.html Io utilizzerei questi 3: 1) Value Object Exchanges data between tiers. I Value Object non sono altro che oggetti serializzabili con metodi get e set. _Non sono a conoscenza di come viene gestita la loro persistenza_. 2) Value List Handler (~Iterator) Manages query execution, results caching and result processing. Utilizza i DAO per leggere i dati e ritorna insiemi di Value Objects. 3) Data Access Object Abstracts data sources, provides transparent access to data. Da utilizzare per ogni lettura/scrittura. Un DAO fornisce un'interfaccia di accesso ai dati _indipendente dalla risorsa utilizzata_. Per ogni risorsa utilizzata dovrà esserci un DAOImplementor (DAOPostgreSQL, DAOMySQL e DAOJDO) che farà il lavoro sporco. La scelta della risorsa può essere fatta a runtime. ... Pensandoci bene forse questa architettura ha senso con JDBC ma non con JDO, cmq almeno per adesso ci permetterà di fare un confronto tra le varie tecnologie senza dover ogni volta stravolgere l'applicazione. Un'ultima cosa, date un'occhiata qua: http://jakarta.apache.org/turbine/torque/ http://jakarta.apache.org/turbine/torque/tutorial.html http://jakarta.apache.org/turbine/torque/peers-howto.html http://jakarta.apache.org/turbine/torque/criteria-howto.html Da quel che ho capito leggendo velocemente, Torque è un tool che dato un database ti può creare i sorgenti delle classi che lo mappano. Molto fico. Io per questo venerdì ci sono, ci si becca in sede. Ciao, -- Davide |
|
From: <za...@di...> - 2002-04-08 19:59:38
|
Ho valutato alcune opzioni relative alla persistenza Object to Relational= e mi sto orientando su JDO. Pro: - E' lo standard di domani - Impressionante il lavoro che fa dietro alle quinte per evitarti di scrivere una sola riga di codice SQL - Genera la struttura del database in funzione agli oggetti da rendere persistenti (quindi in definitiva non si ragiona mai a livello di database ma sempre = e solo a livello di oggetti Java) Contro: - Non esistono ancora implementazioni OpenSource - Nell'implementazione che ho scelto (RexIP, vedi dopo) viene usata una tecnica di modifica dei file .class (quindi interviene dopo la compilazio= ne dei sorgenti) per aggiungere in modo trasparente il codice necessario all= a persistenza (!!) - Perplessit=E0 sulle prestazioni di JDO "in the large" Tutto sommato JDO =E8 affascinante e credo meriti in ogni caso di essere conosciuto, anche solo per poterlo confrontare a soluzioni che usano JDBC= o J2EE. L'unica implementazione OpenSource =E8 Castor, incompleta e non completam= ente standard (anche se alcuni analisti riconoscono il valore delle modifiche = che hanno introdotto rispetto allo standard di Sun). Restano i (pochi) prodotti commerciali. Tra questi ho scelto JDO di RexIP (http://www.rexip.com), perch=E9 =E8 utilizzabile in una versione Developer che non =E8 limitata a tempo n=E9 = a funzionalit=E0 ma solo a "scalabilit=E0": il pool di connessioni lavora s= olo con una connessione (in pratica il pool non =E8 attivo ma per noi questo =E8 = meno di un problema). Mi sembrava di avere visto che un altro produttore, http://www.prismtechnologies.com, prevedesse una licenza free per l'utili= zzo senza fini di lucro del suo prodotto OpenFusion, ma poi non sono pi=F9 riuscito a trovare sul sito questa informazione. Detto questo, potremo procedere cos=EC: se questa settimana avete tempo d= i valutare JDO e siete d'accordo di usarla, potremo trovarci venerd=EC 12 i= n sede per stabilire come partizionare il lavoro e chi far=E0 cosa. Altrimenti rimarr=E0 comunque valida l'occasione dell'assemblea. -- Fabrizio Zacch=E9 aka Zack Mandrake Users Club Member |
