Newsgroup: it.comp.java
Titolo: Stampa unione in java lato server

Scusate il soggetto non è dei più esplicativi ma è quanto di meglio ho 
saputo inventare per descrivere un problema abbastanza articolato.
Vi spiego l'attività che mi trovo a dover gestire.
La mia webapp (tomcat) ha bisogno di mettere a disposizione dell'utente 
dei "modelli di stampa".
L'utente deve avere un editor (quanto più wysiwyg possibile) in cui 
costruire il suo modello composto da normale testo (con formattazioni, 
tabelle e quant'altro) e da alcuni "campi". L'editor deve essere molto 
integrato con l'applicazione web in quanto questa deve gestire il 
versioning del file e vorremmo evitare di dover fare l'upload del file 
dopo averlo editato con un editor esterno. Finora abbiamo utilizzato un 
editor XHTML fatto in javascript.
Una volta generato il modello questo verrà utilizzato (da un altro punto 
dell'applicativo e da utenti diversi) per generare delle stampe, 
sostituendo i campi con i loro valori effettivi.
Fin quì si tratterebbe della generazione di un report, ma ora viene il 
bello.
Dopo aver generato il report (e averlo memorizzato sul server) questo 
deve essere modificabile dall'utente che l'ha generato per aggiungervi 
dell'ulteriore testo, modificare quello che è stato precompilato, 
modificare la formattazione, ecc. Anche in questo caso si richiede di 
essere estremamente wysiwyg (es. di lamentela del cliente: la larghezza 
della pagina non corrisponde a quella di stampa). Anche per questo 
finora abbiamo usato l'editor XHTML dato che dire all'utente "fai il 
download del file, lo modifichi, fai l'upload" è impensabile.
Le modifiche devono essere versionate sul server, e deve essere 
possibile generare un file PDF e firmarlo digitalmente (da parte del 
server). Per la generazione del PDF a partire dall'XHTML abbiamo 
utilizzato FOP, che ci ha dato qualche grattacapo devo dire.
In pratica dobbiammo realizzare qualcosa di simile alla stampa unione di 
word, ma spostando tutta la gestione dei file e dell'unione lato server 
e tutta l'interazione deve avvenire tramite browser.
A questo punto stiamo accettando l'idea che la soluzione XHTML + FOP non 
è adeguata alle nostre esigenze e stiamo cercando alternative.
Alcune esigenze:
1) XHTML non soddisfa le esigenze di fedeltà di stampa.
2) possibilmente l'editor dei modelli e dei report generati deve essere 
unico.
3) L'editor dei modelli deve guidare l'utente per la costruzione del 
modello stesso (inserimento dei campi) e quindi richiede che possa 
essere "esteso" da noi.
3) è possibile richiedere l'installazione di un software su tutti i 
client ma...
4) no a tecnologie proprietarie (niente Office)
5) il salvataggio deve essere trasparente per l'utente (clicka su un 
link, gli si apre l'editor, fa le sue modifiche, salva, e le modifiche 
devono essere riportate automaticamente sul server).
Qualcuno ha mai dovuto affrontare problematiche del genere? Oppure 
qualcuno mi sa dare indicazioni su quale direzione prendere per cercare 
di trovare informazioni in merito? (magari altri newsgroup)
Attualmente stiamo investigando la possibilità di utilizzare OpenOffice, 
ma ancora non sappiamo se sia una strada percorribile. E' possibile 
effettuare il passo di "unione" da java intervenendo sul file openoffice 
tramite qualche api? E' possibile generare il pdf partendo dal file 
OpenOffice?
Qualcuno ha informazioni in merito?
Grazie,
Andrea

 saputo inventare per descrivere un problema abbastanza articolato.
[CUT]
Ciao Andrea.
Non mi è chiaro il motivo per cui la scelta implementativa iniziale sia 
caduta su un applicativo web. Se ho ben capito quel che devi fare io 
vedrei bene un software desktop, preferibilmente webstart, che 
interagisca con OpenOffice attraverso le API UNO 
(
http://api.openoffice.org/
)
Tutta la logica di editing, modelli, stampa unione etc. potrebbe quindi 
essere svolta da OO stesso, mentre il vostro applicativo si limiterebbe a:
1) Fornire l'interfaccia per il versioning e la gestione documentale;
2) Gestire lo scambio dati da e verso il server (upload, download etc.).
Per semplificarvi la gestione del punto due potreste anche sfruttare un 
software di versioning tipo CVS, subversion etc.
HTH
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://ammentos.biobytes.it
Flash tutorial: 
http://ammentos.biobytes.it/quickstart/quickstart.html

 software di versioning tipo CVS, subversion etc.
Personalmente l'idea mi piacerebbe, ma una delle nostre esigenze è 
quella di minimizzare il numero di componenti lato server da configurare 
e gestire. Per quanto possibile la nostra soluzione deve essere 
completamente contenuta all'interno della webapp di tomcat.
Comunque questo problema l'abbiamo già gestito.
Grazie,
Andrea