Quando parli di classi eseguibili, forse ti confondi con la programmazione java classica.
Vaadin può essere utilizzato in progetti java enterprise attraverso application server come tomcat.
Inoltre il programma principale di vaadin risponde come una servlet.
Sicuramente il wizard è un ottimo punto di partenza per capire come come funziona vaadin, dai una lettura alla documentazione , in particolare alla sezione learn sul sito vaadin.comhttps://vaadin.com/learn
Il termine “eseguibile” era certamente inadatto e dal sito purtroppo non sono riuscito a capire come risolvere il mio problema.
La questione è far lanciare con “run on server” una classe come quella prodotta col Wizard. se la copio integralemente (cambiano nome nel costruttore e inserendo il nome della classe creata nell’istruzione @VaadinServletConfiguration(productionMode = false, ui = Nuovaclasse.class
Visto che il comando Run on server genera un errore, immagino che ci siano altre modifiche da apportare… (ai file ivy.xml?)
Ciao
A
Ciao Ragazzi vi scrivo per avere un commento da voi neofiti di questo framework.
Come lo giudichereste in termini di produttività per migrare una web app da un front end fatto in flex? O più in generale riuscite a darmi qualche feedback???
Ciao, premesso che non ho mai lavorato in flex, provo a cimentarmi.
Uso Vaadin da qualche anno e sono abbastanza soddisfatto; volendo semplificare al massimo potre dire che la modalità di programmazione assomiglia a quella con Swing: tutto il lavoro lo fai in java e ti puoi (quasi) dimenticare di avere a che fare con un’applicazione che gira su un browser comunicando con HTTP. Il vantaggio è notevole: puoi utilizzare un solo linguaggio e tutte le librerie esistenti per java (o anche altri linguaggi che girano sulla JVM).
Tutto questo funziona utilizzando dei componenti visuali (textbox, tabelle, combobox, ecc.) che hanno una parte client che gira sul browser ed una parte server che gira sull’application server; la comunicazione tra le due parti è gestita in maniera trasparente dal framework, quindi le interazioni dell’utente generano eventi sul server e le modifiche sul server vengono riportate automaticamente sul browser.
Gli svantaggi di questa architettura sono principalmente:
un utilizzo più elevato della rete, anche se non è detto: dipende dal tipo di applicazione.
di conseguenza tempi di risposta più lunghi (un generico comando deve arivare sul server, essere processato e i risultati assere applicati sul client
un utilizzo di memoria maggiore sul server: per ogni elemento dell’interfaccia grafica sul browser deve esistere la relativa controparte sul server, memorizzata nella sessione di ogni utente
Per questo ti consiglio di utilizzare Vaadin per applicazioni che non necessitino di un’interattività molto elevata (ad esempio non per giochi); per esempio, per creare interfacce web a basi di dati va benissimo.
Il framework è facilmente estendibile creando ulteriori componenti: puoi crearli in java usando GWT (integrato) oppure direttamente in javascript; in ambedue i casi sono formiti meccanismi che semplificano la comunicazione con il server.
La documentazione è ottima: esiste un libro gratuito che copre tutti gli argomenti principali; esiste un wiki con numerosissime voci e un canale su Youtube con tanti tutorial; inoltre il forum (la versione inglese) è molto attivo e contiene già le risposte a quasi tutte le domande che possono venire in mente.
Il framework base è open source e gratuito; esistono centinaia di componenti aggiuntivi di cui la maggior parte gratuiti e alcuni a pagamento; i costi sono sempre molto ragionevoli. Volendo è possibile acquistare assistenza aggiuntiva.
Ogni versione del framework (adesso siamo alla 7) viene supportata e aggiornata per almeno 5 anni (in genere per più tempo).
Una nota negativa è sulla velocità di layouting: se hai form con centinaia di componenti i tempi per visualizzarli non sono particolarmente eclatanti.
Io ho utilizzato Vaadin per realizzare con successo diverse applicazioni in tempi sempre molto limitati per cui ti consiglio caldamente di provarlo.
Ciao Claudio ti ringrazio per il tempo che hai perso per darmi questi interessantissimi point of view sull’architettura e su come ci si comporta (dato che quando si sceglie un framework i pro ed i contro si incominciano a palesare verso il secondo-terzo anno di sviluppo).
La mia esigenza è trovare (se esiste ma al momento mi sembra ancora di no) un framework di frontend che possa prendere il posto di apache flex che a causa della geopolitica ad alto livello sembra voler essere estromesso dal panorama mobile/desktop.
Ho iniziato una sw selection e mi è sembrato che vaadin possa essere un valido compromesso anche se i dubbi che nutro, dato la nostra webapp si un gestionale ma a livelli di sap con 4 anni di sviluppo di un team di 10 persone e maschere mediamente complesse, sono i rallentamenti che puo’ produrre lato client tale architettura nonchè l’appesantimento del tomcat che attualmente rappresenta per noi una forte criticità.
Ti ringrazio nuovamente e ringranzio in anticipo chi vorrà scrivere due righe con la sua esperienza su questo framework.
I miei compliemti a Claudio che ha spiegato molto bene l’architettura di vaadin.
Per quel che riguarda la mia esperienza, vaadin è veramente un ottimo prodotto, io lo uso da almeno 3 anni in un applicativo
http://www.centrico.it ( Non so se i link sono ammessi in questo forum )
Sono daccordo sul fatto che lo sviluppo di applicativi data oriented con vaadin è assolutamente sostenibile, i vantaggi che da ( ti puoi dimenticare della gestione cross browser ) sono di lunga superiori alla possibile pesantezza.
Tieni presente che se lo sviluppo è fatto bene, problemi di lentezza non ce nesono.
Vaadin è cresciuto molto in questi anni e sembra che continuerà a crescere.
Spero che anche il mio contributo ti sia utile per la scelta.
Non vorrei averti spaventato con il mio post precedente: ti confermo quanto detto da Giovanni e cioé che in generale per applicazioni di tipo gestionale non ci sono problemi.
La mia applicazione gestionale più grossa (diverse centinaia di maschere, alcune decine di utenti collegati) gira senza creare alcun problema sul misero sistema che i nostri sistemisti ci mettono a disposizione (macchina virtuale con 4 Gb e 2 processori), insieme a qualche decina di altre applicazioni più piccole e ad un’altra istanza di Tomcat con Liferay.
Ciao a tutti,
mi presento, mi chiamo Stefano, programmo da… troppi anni, ma continuo a farlo con soddisfazione. Sono titolare di una SH, sviluppiamo web app “gestionali”. Attualmente utilizziamo WaveMaker, un ottimo tool OS che purtroppo, dopo il cambio di proprietà sta, dal mio punto di vista, morendo.
Ho appena “inciampato” su Vaadin e creato un accout sul forum.
Vedo che la sezione italiana non è vivacissima, c’è ancora qualcuno?
Onestamente anche nel forum di WM avevo creato una sezione italiana, alla fine poco attiva perchè tutti, correttamente, consultavano quella inglese.
Stefano
Grazie del benvenuto,
onestamente devo ancora installare Vaadin, il tempo è tiranno, prima voglio ovviamente prendere visione della documentazione, post ecc.
Se avete qualche consiglio “risparmia tempo” per uno che di Vaddin conosce solo il nome è il benvenuto.
Installa il plugin di Eclpse (io uso quello, non so dirti bene per gli altri IDE) e potrai immediatamente generare un progetto funzionante. Oppure puoi usare Maven.
Per casi specifici consulta il forum (in inglese è molto più frequentato)
Architettura di base:
il framework contiene un certo numero di componenti visuali (per es. TexfField, Table, Tree) che hanno una parte client (in java compilato in javascript con GWT) che funziona sul browser ed una parte java che gira sull’application server
Un componente viene creato sul server in java, automaticamente la sua controparte client viene creata sul browser e la sincronizzazione tra le due parti è gestita dal framework
un comando eseguito dall’utente (per esempio il click su un pulsante) viene automaticamente inviato al server come EVENTO
puoi aggiungere ad ogni component dei listener che vengono eseguiti quando un evento viene ricevuto.
nel listener puoi modificare lo stato dei componenti (ad esempio modificare i dati mostrati in una tabella) e automaticamente questi cambiamenti saranno comunicati al client
l’effetto netto è che puoi programmare la tua applicazione web comodamente il java, in maniera concettualmente simile ad un’applicazione client java
Alcuni pensieri in ordine sparso:
Vaadin è ideale per creare applicazioni web complesse
Ti fornisce gli strumenti per creare l’interfaccia grafica dell’applicazione, per il resto (connessione al Db, logica applicativa, ecc) puoi usare qualsiasi libreria o linguaggio che funziona sulla JVM.
Non c’è più bisogno di preoccuparsi delle differenze tra browser: ci pensa il framework
per ogni utente lo stato dell’interfaccia grafica è memorizzato nella relativa sessione del server: quindi l’applicazione non è stateless: se ci sono migliaia di utenti collegati bisogna tenerne conto.
hai a disposizione dei componenti che gestiscono la disposizione degli altri componenti, sempre in maniera indipendente dal browser
puoi creare componenti aggiuntivi in java (GWT) o javascript o utilizzare quelli (alcune centinaia) presenti tra gli add-on
https://vaadin.com/directory
Ciao Claudio e grazie delle tue utili indicazioni.
Purtroppo la voglia di iniziare è tanta ed il tempo è poco, ma credo di non dire niente di nuovo.
Senz’altro terrò conto della sezione inglese del forum anche se questo porta a devitalizzare il nostro :-(.
Dal momento che decidere lo strumento da utilizzare per lo sviluppo nei prossimi anni è, anche (o forse proprio) per una piccola struttura, una scelta critica, è ovvio che si prenda visione di diverse possibilità.
Al momento oltre Vaadin abbiamo visto, sulla carta, ZK, openXava e PrimeFaces.
Non voglio fare la “banale” domanda: quale è meglio, ovvio che ogni considerazione è benvenuta. Nel forum ho trovato questo post https://vaadin.com/forum/#!/thread/3875659/3875658, dove Claudio interviene, che mi ha lasciato un poco perplesso. E’ vero che risale a due anni fa, ma è cambiato qualcosa o questo resta un punto debole di Vaadin?
Ciao, visto che sono tirato in ballo ti rispondo subito sul problema affrontato due anni fa sul forum, poi alcune considerazioni sugli altri framework. Tieni a mente che non uso ZK o Primefaces da tempo, quindi le mie informazioni su questi potrebbero essere datate.
Vaadin utilizza una sua astrazione per rappresentare i dati che vengono mostrati nei controlli utilizzando il databinding: una “riga” di dati (corrispondente ad un record in un DB relazionale) è chiamata Item; un singolo valore di un item è rappresentato da una Property; Un Container contiene un elenco di Items.
Questa rappresentazione da una parte aggiunge flessibilità, ma dall’altra è in confilitto con l’astrazione comune utilizzata in java in cui un record è rappresentato da una oggetto, un singolo valore da un campo di quell’oggetto e un insieme di record da una lista (nota che gli altri framework utilizzano direttamente questo tipo di rappresentazione).
Esistono degli oggetti che adattano la rappresentazione di Vaadin a quella comune di java (BeanItem e BeanItemContainer), ma non sono ottimizzati (e il BeanItemContainer non è “lazy” quindi carica in memoria tutte le righe), quindi se utilizzati per visualizzare migliaia di righe per molti utenti (come nel post sul forum) le prestazioni non sono delle migliori.
Il componente Table, e la nuova Grid, sono invece “lazy” di default lato client, cioè caricano dal server solo le righe che sono al momento visualizzate.
La soluzione al problema è quindi quella di utilizzare un container lazy, che mantenga nella memoria del server solo le righe visualizzate sul client. Tra gli addon di Vaadin esistono diversi Container di questo tipo, ma io consiglio quello presente in “Viritin”, perché è semplice da usare (basta fornire un metodo che restituisce il numero totale delle righe ed uno che restituisce la lista delle righe comprese tra due indici) ed è creato e mantenuto da uno dei principali programmatori di Vaadin, quindi è possibile che prima o poi ce lo ritroviamo incluso nel framework.
Utilizzando un container “lazy” puoi visualizzare elenchi di milioni di elementi senza problemi di memoria (io ho provato con un milione).
Quello che ho detto vale se usi i componenti Table o Grid di Vaadin per visualizzare in un dato istante un numero limitato di righe (qualche decina) da un elenco comunque lungo, lasciando a questi la gestione della barra di scorrimento; se invece vuoi visualizzare una pagina contenente una tabella di migliaia di righe presenti contemporanemente allora probabilmente incorrerai in problemi di memorie e prestazioni.
Per quanto riguarda il contronto con gli altri framework alcune considerazioni:
Vaadin ti dà la garanzia che una major version (adesso siamo alla 7) sia mantenuta per almeno 5 anni dalla prima edizione E fino all’introduzione della major version successiva alla successiva (quindi la 6 è mantenuta fino a quando non esce la 8 anche se sono passati più di cinque anni). Inoltre l’azienda è in espansione e ha tutte le carte in regola per restare sul mercato a lungo.
ZK ha alcuni componenti più “potenti” di quelli di Vaadin, ad esempio quello per visualizzare Tabelle di dati (confronta i due demo), ma per sfruttare alcune funzionalità avanzate del framework ti costringe a comperare la versione a pagamento. Per Vaadin il framework è completamente gratuito ma alcuni componenti aggiuntivi (quello per i grafici, i test, i fogli Excel) sono a pagamento.
Vaadin e ZK non aderiscono a standard e ti astraggono entrambi dal fatto che stai creando un’applicazione web: a parte casi particolari lo stile di programmazione è concettualmente simile a qullo di un’applicazione client-server.
Primefaces ha un’enormità di componenti, aderisce ad uno standard java (JSF) e ha un grado di astrazione dal mezzo sottostante (html + http) inferiore: questo può a seconda dei casi essere meglio o peggio.
L’idea che mi sono fatto delle prestazioni è che in generale Primefaces sia più performante se devi visualizzare pagine contenenti molte decine (o centinaia) di componenti.
Il consiglio che provo a darti e che se devi creare applicazioni che assomigliano alle vecchie client-server (molte finestre di dialogo, una singola pagina con swapping dei contenuti) ti conviene usare ZK o Vaadin; in caso contrario valuta Primefaces.
Buongiorno a tutti,
anch’io mi sono avvicinato a Vaadinc - come altri che hanno qui postato - in quanto sto valutando insieme ai componenti del mio team quale framework web adottare per lo sviluppo di applicazioni gestionali (ERP) enterprise-level. Attualmente abbiamo un ERP basato su Java EE con client swing, in cui abbiamo sviluppato componenti custom per adattarli alle nostre esigenze… non nascondo che Vaadin ha delle caratteristiche molto interessanti, tra cui proprio la customizzabilità dei componenti, e l’indubbio vantaggio che consente di sviluppare client e server side con un’unico linguaggio. Le maggiori perplessità sono legate al fatto che
non si tratta di uno standard (nemmeno de facto), che non siamo riusciti a trovare delle informazioni sulla scalabilità effettiva del framework e dal timore che prima o poi si assista ad uno shifting verso i web components nello stesso framework (ossia che venga progressivamente abbandonato il supporto alla generazione di interfacce web usando Java in favore di componenti stile Polymer ed altre soluzioni analoghe).
Voi che l’avete usato cosa mi sapete dire ?
Per quanto riguarda gli standard Vaadin non aderisce a nessuno (tipo JSF), quindi se in futuro decidessi di cambiare framework saranno dolori! In pratica anche utilizzando uno standard come JSF probabilmente saresti in qualche misura (minore) legato allo specifico framework utilizzato (Primafaces, ICEFaces, …), dato che probabilmente cederai alla tentazione di utilizzare i componenti più avanzati (rispetto allo standard) da questo forniti.
Il vantaggio principale di Vaadin rispetto a JSF è che astrae in misura maggiore dal protocollo HTTP, quindi è probabile che la struttura delle tue applicazioni sia più simile a quelle che utilizzano swing e dunque la migrazione più semplice.
Sulla scalabilità la mia esperienza nel creare applicazioni gestionali è che, con un po’ di attenzione, non ci sono grossi problemi, pur avendo noi dei server piuttosto sottodimensionati sia per capacità di elaborazione che per memoria. Ovviamente sarebbe meglio eseguire dei test su un prototipo dell’applicazione.
Se non li hai già trovati ecco alcuni link su scalabilità e stree test con Vaadin:
per quanto riguarda i web component i progetti (
https://vaadin.com/components ) prevedono la trasformazione dei componenti di Vaadin per essere utilizzati ANCHE lato client, secondo tale standard. Quindi probabilmente assisteremo alla creazione di una nicchia di utilizzatori che programmano in javascript lato client.
Tuttavia il core business della compagnia è la creazione di applicazioni web in java, e non credo che a breve la cosa cambierà (sarebbe un suicidio per loro), quindi ritengo piuttosto sicuro un investimento in tale senso. Per quello che ho visto nel corso del tempo (diversi anni) le assicurazioni sul periodo di manutenzione delle varie versione del framework (almeno cinque anni dalla prima edizione di una major version E fino all’uscita della major version successiva alla successiva) sono sempre state mantenute.