Newsgroup: it.comp.java
Titolo: Chi usa Velocity?

Sto usando velocity di apache dentro le servlet, al posto delle JSP, e lo
trovo piuttosto divertente.
Oggi per esempio l'ho usato per generare un report html, da stampare tramite
browser rispettando le dovute interruzioni di pagina.
Qualcuno di voi l'ha provato?
Mi stavo chiedendo per esempio se facilita in qualche maniera il richiamo
dei parametri dopo un POST o GET.
Nei tutorial di 
javaworld.com
 c'e' una presentazione rapida e ben fatta
Enrico
(btw, se ie5.5 visualizza una riga di una tabella con uno sfondo grigio, per
esempio, c'e' un modo per far si che tale riga evidenziata venga stampata su
una stampante b/n? Evidentemente ie toglie gli attributi di colore quando
stampa, per cui questo tipo di evidenziazioni scompare)


Non saprei, non ho mai affrontato questo problema, direi che si tratta di un classico
prova e riprova :-); puoi provare anche a chiedere in un gruppo che parli esplicitamente
di html.
Ciao,
    Bruno.
|
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://bbruno.fasturl.it
|
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola
|

 Ci passi il link? Mi sa che potrebbe essere interessante.
www.javaworld.com
, poi basta cliccare su Tutorials e lo si trova subito


Okay, grazie, asap ci do' un'occhiata 


JSP ha avuto molto successo e anche molte critiche :)). Questo perché il
primo impatto di JSP sugli sviluppatori, è stato mischiare html e java (più
javascript, vbscript e chi più ne ha...).
Io non ho mai usato velocity, ma quì usiamo delle classi sviluppate
internamente che fanno qualcosa di simile, credo sia un "subset" di ciò che
può fare velocity. Una soluzione "proprietaria" purtroppo.
Però quì le utilizziamo in combinazione a JSP, e devo riconoscere che
qualche vantaggio c'è:
- Ricompilazione al volo
- Semplicità di deployment
- Possibilità di utilizzare tag libraries.
Sulla configurazione delle JSP, non è che ci sia un gran lavoro da fare,
anzi per i servlet devi modificare il web.xml, molto spesso.
Per ciò che riguarda i test, quando si tratta di viste, non credo che ci sia
moltissimo da testare, sui controller invece, certamente sì, per questo che
anche Sun (se non sbaglio) consiglia di utilizzare dei servlet come
controller e delle JSP come viste. Io generalmente anche per i controller
uso JSP, cercando di far sì che i controller siano molto brevi e che
demandino la logica di controllo a dei JavaBean, che eventualmente poi
possono essere riutilizzati in una application. Bisogna pensare che tutto
ciò che sta dentro una JSP viene messo in un metodo, e i metodi, si sa non
devono mai superare un certo numero di linee.
Sulla semplicità d'uso credo che JSP non sia più complesso di scrivere una
servlet, infondo JSP è nato per semplificare la scrittura di servlet, tra le
altre cose.
Tutto questo, secondo la mia modesta opinione :)
Fondamentalmente, non trovo molte differenze tra lo sviluppo di una servlet
e quello di una JSP, per cui ogni strada (che funziona) è buona.
Di velocity ho un'ottima impressione comunque, spero di dargli uno sguardo
appena possibile. Anche jakarta Struts sembra essere molto apprezzato.
~Luigi.


Si, non e' affatto male. Prooovalo!
Ciao,
    Bruno.
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola

 
Ma se non visualizza nulla, non ci sono vantaggi nello scrivere una
JSP al posto di una servlet. Mentre per la scrittura di codice Java,
la servlet è più comoda, e più facilmente debuggabile.
tityrus

 Si, non e' affatto male. Prooovalo!
Ok, provvederň.
Ciao
Luigi

, e più facilmente debuggabile.
Ok. d'accordo (anche se con JBuilder, io debuggo anche le JSP se ne ho
voglia).


Facci sapere come ti trovi. 


 Uhm... no, mai provato. Asap ci do' un'occhiata, ma qui il tempo e'
tiranno!
Appena hai tempo da dedicarci, scaricalo da 
www.togethersoft.com
 (la mia
azienda era esclusivista per l'italia finché non hanno aperto togethersoft
in italia)
Si tratta di uno strumento di design UML, che pian piano si sta avvicinando
ad offrire anche le più complesse funzionalità di IDE evoluti. Poi ha una
serie di tool che ti permettono di integrare meglio il tuo lavoro
utilizzando i vari design pattern messi a disposizione anche dallo
strumento.
E' fenomenale, è "code-centric", cioè dal codice ti tira fuori tutti i
diagrammi del caso... "reverse engineering"...
se hai presente "rational rose", in qualche modo è simile, ma ha delle
features in più che sono sicuro ti piaceranno.
Poi magari ti spedisco una mail così ti racconto qualcosa su questo
strumentillo.

 diagrammi del caso... "reverse engineering"...
"roundtrip engineering", nel senso che il tutto e' sempre allineato automaticamente 
e non c'e bisogno di fare "reverse engineering".
Chi ha assistito alla giornata su UML a Milano organizzata qualche mese 
fa da 
www.programmazione.it
 (c'era anche TogetherSoft, di cui per la 
cronaca Sun e' partner), sa cosa penso perche' cerco sempre di dire la 
verita', anche in situazioni difficili... :)
posso riassumere il tutto dicendo che i case per UML hanno dei problemi 
grossissimi nella loro interpretazione di UML, e favoriscono utilizzi di 
UML *errati*.
Sia chiaro che non discuto le caratteristiche tecniche di Together, che 
ho utilizzato parecchio e mi e' sempre piaciuto... ma col tempo ho 
maturato l'idea che tutti i case UML siano "flawed". Sono contento che 
nella stessa giornata anche Carlo Pescio, che ho sempre stimato 
moltissimo, abbia espresso piu' o meno le stesse opinioni (anzi, lui ci 
e' andato giu' mooolto piu' pesante).
Comunque, per argomentare un po', Fowler classifica giustamente i 
diagrammi UML secondo la "perspective" (tutti, anche se la cosa e' 
evidente soprattutto con i class diagram):
Conceptual
i diagrammi rapresentano i concetti del dominio sotto studio: qui piu' o 
meno gli oggetti rappresentano oggetti del mondo reale, cosa che *non* 
si puo' dire quando si parla di OOP, come ho letto in qualche altro 
thread: gli oggetti *non* sono controparti software degli oggetti nel 
mondo reale (e' una common misconception). questi diagrammi sono pero' 
utili per capire i problemi... e potrebbero servire anche in ambiti 
diversi dal software, che so, per modellare il campionato di calcio o la 
struttura del vostro film preferito.
Specification
abbiamo abbassato il livello: ora guardiamo piu' o meno le interfacce, 
ma non le implementazioni (dunque diamo un occhio ai tipi). Questi sono 
i diagrammi che resistono di piu' nel tempo e sono anche i piu' utili.
Implementation
abbassiamo ancora: i diagrammi qui rappresentano l'implementazione vera 
  e propria. Questi diagrammi sono i piu' usati, ma anche in assoluto i 
meno utili. Riempiono di dettagli inutili e sono un sostituto grafico 
(povero, aggiungo io) del codice, che *non* e' l'utilizzo migliore di UML.
UML da il meglio di se' quando giustamente riesce a comunicare qualcosa 
a chi legge i diagrammi: per mettere in pratica questo apparentemente 
banale concetto pero' e' necessario che:
- ci siano pochi diagrammi, che mettano in evidenza cose che non si 
evincono in altri modi
- che i pochi diagrammi siano chiari e non dettagliati come il codice, 
altrimenti, mi leggo il codice. (se poi sono organizzati secondo 
l'intelligente approccio di Pescio - leggetevi UML Manuale di stile - 
ancora meglio) In parole povere, che siano di perspective 
"Specification" o nel caso di analisi, "Conceptual".
- che non ci siano diagrammi di tutto!
e l'approccio di Together e gli altri case e' quello di creare diagrammi 
UML per tutto il codice (tanto e' gratis, c'e' il roundtrip 
engineering...). Che equivale a non disegnare nessun diagramma...
Un po' come fare una ricerca su internet e trovare 1.000.000 di 
risultati: c'e' molta differenza fra non trovarne nessuno ed un milione?
Che differenza c'e' fra 1000 righe di codice e le decine di quadratini e 
freccette visualizzate dal roundtrip engineering di Together, che si 
intersecano senza pieta' sul vostro schermo? Cosa vi comunicano? cosa 
documentano? E' piu' semplice fare click col tasto destro sul quadratino 
ed aggiungere un attributo "pippo" piuttosto che scrivere "private 
String pippo"? Se UML fosse tutto qua, sarebbe un linguaggio di 
programmazione visuale, il che non e': Unified *Modeling* Language 
implica la modellazione, ossia la semplificazione di una realta' a scopo 
di studio preventivo.
Un po' come i modelli delle auto che servono agli scopi piu' disparati: 
non sono mai completi, ma servono solo per mettere in risalto questa o 
quella caratteristica (aereodinamicita', ecc.). Pensate se ogni singolo 
modello fosse completo e funzionante in tutto e per tutto, non si 
farebbe prima a costruire la macchina completa?
Il discorso chiaramente non si esaurisce in queste poche righe, e se 
riuscite procuratevi le slide degli interventi dell'UML Seminar di 
programmazione.it
 (quelle di Pescio sono molto interessanti)
ciao e sorry per la prolissita' (e per chi mi sente a intervalli 
regolari ripetere piu' o meno le stesse cose!)
uL


Ah, si, allora parli di TogetherJ. Figurati, nei tempoi bui lo comprai addirittura.
No, non fa per me, quei tool mi intralciano solo :-D



Piu' o meno le stesse cose? Ma no, guarda che ne dici anche parecchie nuove e
interessanti! Dai, e' un peccato che tu sia passato nella formazione!


 la perspective dipende dal contesto in cui comunichiamo. 
Generalmente gli "implementation" son molto vicini al codice, quindi servono 
a poco se preferisci scrivere codice. "Conceptual e specification" possono 
essere molto utili per comunicare idee senza scrivere un'implementazione.
Ovviamente solo se il bersaglio della comunicazione conosce la notazione. 
:-)
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 interessanti! Dai, e' un peccato che tu sia passato nella formazione!
Perche'? praticamente sono pagato per continuare a studiare (ed insegnare)
quello che mi piace, nel mondo reale e non in quello accademico (nel senso che
in aula c'e' gente che ha bisogno di risposte a problemi reali e non
accademici, non perche' abbia qualcosa in particolare contro le uninversita').
E poi con l'open source posso tenermi in esercizio anche nel "delivery" di
codice....
ciao!
uL
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 rapido che scrivere codice, e complementare ad esso
Spesso sostitutivo. Mica puoi provare ad implementare *tutte* le strade
prima di decidere; un linguaggio piu' ad alto livello aiuta a comunicare
l'essenza delle varie possibilita', specie a clienti o a tester. 
Il problema e' spesso che catturare l'essenza ad alto livello e' piu'
difficile di catturarla come lezione di un tentativo di implementazione. 



Gia', finche' ci riesci, complimenti. Io preferisco stare "sul pezzo" finche' posso: anche
adesso, anche se sono responsabile di area, il naso lo ficco dovunque posso! E per me e'
facile, sono il capoccia :-D
Ciao,
    Bruno.
P.S.
Sorry se non sono stato perfettamente chiaro, ma il limoncello incombe :-D


 facile, sono il capoccia :-D
Peccato che ad un certo punto il "capoccia" non puo' piu' ficcare il naso
ovunque e comincia sempre piu' ad essere preso da problemi diversi.
Non fai in tempo a pensarci su, e *PUF*, sei superato... ;)
E comunque, dopo un po' di "pezzi", mi sono stancato. In Italia si scrivono
sempre le stesse cose: molto meglio l'Open Source. Tornerei sul "pezzo" solo
per una pacchettizzazione per sviluppatori.
ciao



Scusa l'ignoranza, ma che significa?
Ciao,
    Bruno.


 
niente, inventato nella fretta. Intendo solo se dovessi partecipare a 
qualcosa tipo un tool commerciale *vero* (e mi piacerebbe fosse 
server-side: che so, Weblogic, per esempio :)), non progetti custom. E' 
un'esperienza che mi manca e mi piacerebbe fare (possibilmente non in 
Italia). Mi sa che chiedo troppo, quindi me ne sto dove sto!
ciao!
uL

 sapessi quanti curriculum cartacei mi tocca tenere...
Occhio che lě in mezzo c'č anche il mio ;-)

 voglia).
Ok, ma una eventuale eccezione te le lancia il codice della servlet
relativa generata automaticamente, codice che sarà di necessità meno
chiaro del tuo.
tityrus
PS scusa ho scritto _molto_ velocemente, spero di non avere scritto
cavolate


Non condivido tutte le argomentazioni, comunque ti consiglio di provare ad usare Velocity:
sempre servlet fai, ma il codice html lo metti in un file a parte. (hey, magari gia' lo
fai :-D)
Ciao,
    Bruno.
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola

 chiaro del tuo.
Raramente devo aprire la servlet per capire che è successo. Se la JSP è ben
fatta questo si evita: non ha senso mettere logica complessa in una JSP,
come non ne ha metterlo dentro una servlet.
Il codice che fanno "gli altri" è sempre meno chiaro del nostro, bisogna
dire però che ci sono programmatori più imbrattacodice di compilatori
automatici.

 
Scusa non ho potuto leggere per un qualche giorno. Se hai tempo, mi
puoi fare un breve paragone (se ha senso: non conosco Velocity) tra
l'utilizzo di Velocity e di Cocoon? Beh, andando in ordine: supponiamo
il mio scopo sia gestire un sito piuttosto complesso e personalizzato,
con alcune pagine facilmente "xml-zzabili" come vetrine, etc.
grazie
ciao
tityrus


Sorry, cocoon non l'ho mai usato in produzione, ne ho solo letto. Che cosa ti serve sapere
di velocity?


Gli ho dato uno sguardo.
Mi sembra molto carino, ma mi sfugge una cosa: Velocity è uno scripting
language che permette di riempire un layout html (o altro) con dei contenuti
dinamici attraverso semplici costrutti.
Quindi si mischia codice Velocity (con tanto di iterazioni) con codice HTML.
Non si ricade nel problema del codice java nelle JSP ?
Qualcuno mi spiega perché sia giusto mischiare codice "velocity" con codice
html mentre invece è sbagliato mischiare (con la giusta moderazione) codice
Java con codice HTML?
(Il template engine che usiamo noi privatamente prevede solo dei "marcatori"
che identificano blocchi e variabili, è molto poco invasivo, e ciò mi sembra
una qualità. ma è il primo che ho utilizzato quindi non saprei fare
raffronti)
Luigi.

Cocoon ho provato a usarlo, molto bella l'idea, ma mi sembra troppo
complicato...
Se l'html te lo fanno dei webdesigner potrebbe non essere sempre semplice
riuscire a tirar fuori l'XSL e l' XML per ottenere il risultato voluto
(anche se ci sono dei generatori automatici, chi conosce XML split ? :) ).
Luigi.


Infatti Velocity va usato proprio cosi' nel 95% dei casi: esistono pero' delle situazioni,
tipicamente quando si trattano collezioni di oggetti, in cui lo stesso blocco deve essere
ripetuto piu' volte. Ecco perche' personalmente apprezzo potere fare questo:
    #foreach($dipendente in $dipendentiAzienda)
    <tr>
        <td>$dipendente.getCognome()</td>
        <td>$dipendente.getNome()</td>
    </tr>
    #end


 
Si può addirittura avere un esempio minimo (proprio due righe) di come
separa html e logica?
tityrus
PS: cocoon lo sto solo guardando, mai usato neppure io.

Ok, thanks :)
In pratica anche JSP può essere usato in modo da non accoppiare logica alla
vista. Concordo che, come tu dici, inconsapevolmente il programmatore meno
smaliziato sia indotto a farne cattivo uso.
Grazie mille...
Luigi.


Io dire: "In *teoria* anche JSP puo' essere usato in modo da non accoppiare logica..."
In pratica nessuno lo fa. Una cosa e' lavorare forzatamente con un contesto statico,
un'altra e' avere la possibilita' di eseguire dinamicamente tutto quello che ti pare
concedendoti anche tutta la richhezza di un liguaggio di programmazione OO.
Comunque questo e' solo un'aspetto assai importante) del problema. Come testi una pagina
JSP?


>Come testi una pagina JSP?
Me lo dicono anche i tuoi 2 colleghi (Andrea e Maspes) quì :)
Comunque, certamente grazie soprattutto al layout engine che abbiamo quì, le
viste delle nostre JSP non coinvolgono la logica.
Noi usiamo delle JSP di vista (che interagiscono con il template engine) e
delle JSP controller che per lo più si appoggiano a JavaBean e fanno uso
della sessione. La cosa funziona.
Giustamente tu dici che non si possono testare, ed è vero che junit non può
testarle. Tra l'altro, sto cominciando ad usarle (e in JBuilder 6 ci sono
anche dei wizard automatici). Però non tutti usano Junit, alcuni testano il
software semplicemente eseguendolo e vedendo che succede (anche se poi non
possono replicare i test con delle fixture). E' pur sempre il modo in cui il
software è sempre stato testato (purtroppo).
Il beneficio delle servlet è che sono oggetti, e come tali puoi anche avere
una gerarchia complessa, metodi e proprietà etc. E come tali possono essere
usate con un tool come junit. Però non credo che siano molti quelli che
usano le servlet in questo modo. La maggior parte delle servlet che ho visto
io estendono tutte da HttpServlet direttamente e prevedono giusto doPost o
doGet in cui c'è quello che io metterei in una JSP (comunque roba semplice,
non molto da testare) .
Questo è una mia JSP controller, e la logica business è demandata ad un
SessionBean Sportello :
<%@ page language="java"
         contentType="text/html"
%>
<%@ page import="it.csi.sert.anagrafe.*" %>
<%@ page import="it.csi.sert.anagrafe.util.*" %>
<%@ page import="java.math.BigDecimal" %>
<%@ page import="java.text.*" %>
<%@ page import="java.sql.Timestamp" %>
<%
    String codice = request.getParameter("codice");
    String cognome = request.getParameter("cognome");
    String nome = request.getParameter("nome");
    String sesso = request.getParameter("sesso");
    DateFormat datefmt = new SimpleDateFormat("dd-MM-yyyy");
    String birthDate = request.getParameter("giorno") + "-" +
                       request.getParameter("mese") + "-" +
                       request.getParameter("anno");
    Timestamp dataNascita = null;
    try {
        dataNascita = new Timestamp(datefmt.parse(birthDate).getTime());
    } catch (Exception pEx) {
        pEx.printStackTrace();
    }
    String codiceStatoNascita = request.getParameter("stato");
    String codiceProvinciaNascita = request.getParameter("provincia");
    String codiceComuneNascita = request.getParameter("comune");
    String codiceFiscale = request.getParameter("codiceFiscale");
    Sportello sportello = new SportelloClient().getSportello();
    sportello.updateAssistito(codice, cognome, nome, sesso, dataNascita,
                              codiceStatoNascita, codiceProvinciaNascita,
                              codiceComuneNascita, codiceFiscale );
    response.sendRedirect(request.getContextPath() +
        "/anagrafe/view/pop_anagrafica.jsp" +
        "?codice=" + codice);
%>
Non c'è molto da testare, il 90% son tutte così.
Questa è una JSP "view", sono spesso anche più lunghe ma sono tutte
operazioni ripetitive di popolamento di blocchi o di settaggio variabili.
Comunque capisco quello che tu dici, e condivido moltissimo di quello che
dici (soprattutto sull'importanza dei test)
Gigi.


Supponiamo di voler generare dinamicamente una pagina html contenente un report dei libri
disponibili al prestito da parte di una biblioteca. Ecco la logica che dovresti inserire
nella servlet dedicata alla funzione:
    // eseguo la logica di business
    Enumeration libriDisponibili = biblioteca.libriDisponibili();
    // creo il contesto
    VelocityContext context = new VelocityContext();
    context.put("libri_disponibili",libriDisponibili);
 
    // carico il template ed effettuo il merge con il contesto
    Template template = Velocity.getTemplate("libri_disponibili.vm");
    template.merge(context,response.getWriter());
Nota che il lavoro e' sempre uguale, a pare l'invocazione alla logica di business: questo
poi ti porta, rifattorizzando, a dimenticarti completamente della servlet :-D in questi
casi.   
Ah, ecco il template di Velocity:
<HTML>
  <BODY>
    <TABLE>
     #foreach ($libro in $libri_disponibili)
       <TR>
         <TD>
           $libro.titolo()
         </TD>
         <TD>
           $libro.autore()
         </TD>
         </TR>
     #end
    </TABLE>
  </BODY>
</HTML>
 
Il codice tradizionale, puro servlet-based, e scritto pure bene :-D, sarebbe stato
qualcosa del genere:
    PrintWriter writer = response.getWriter();
 
    writer.println("<HTML>");  
    writer.println("  <BODY>");  
    writer.println("    <TABLE>");  
    Enumeration libriDisponibili = biblioteca.libriDisponibili();
    while(libriDisponibili.hasMoreElements())
    {
        writer.println("      <TR>");
 
        Libro ilLibro = (Libro)e.nextElement(); 
        writer.println("        <TD>");
        writer.print("          ");
        writer.println(libro.titolo());
        writer.println("        <\TD>");
        writer.println("        <TD>");
        writer.print("          ");
        writer.println(libro.autore());
        writer.println("        <\TD>");
        writer.println("      </TR>");  
 
    }
    writer.println("    </TABLE>");  
    writer.println("  </BODY>");  
    writer.println("</HTML>");  
Allora, cosa succede quando l'utente vuole cambiare ad esempio l'allineamento delle
colonne nella tabella? Nel primo caso ti limiti a toccare il template, nel secondo
smanetti con il codice. Stessa cosa se:
- vuole vedere un altro attributo del libro, che so, l'autore
- vuole inserire uno stylesheet in modo da dare un'aspetto uniforme al sistema
- ecc.ecc.
Ho risposto alla domanda? Se hai dei dubbi, posta.



Sto sempre traducendo... moolto lentamente l'articolo di Kent! Lo so, sono inefficiente
:-(


 validazioni incrociate?
Andrea :) so che sta facendo una collezione infinita di metodi per validare
i tipi piů impossibili, in alcuni casi ha implementato anche dei controlli
incrociati.


Il problema e': dove mettere il codice di questi controlli? Dal codice che hai postato
precedentemente sembrerebbe corretto metterli nella JSP. In che modo tu fai questi
controlli?
Ciao,
    Bruno.
P.S.
Giuro che non so cosa sta facendo Andrea :-), pur essendo lui un "javista" non fa parte
della mia area.


     Bruno.
Si, sommando con la risposta a Jigi, ho le idee più chiare.
thanks
tityrus