Sia GWT che Wicket sono stateful, basati su oggetti java. GWT è completamente basato su client con funzionalità come l'ottimizzazione javascript, l'ottimizzazione CSS e sono abbastanza nuovo per Apache Wicket.GWT vs Apache Wicket
Più leggo di Wicket più è simile a GWT.
Quindi immagino che la domanda sia: quali sono le differenze tra GWT e Wicket? O sto confrontando le mele con le arance?
È praticamente mele alle arance.
Questo wiki entry riassume alcune delle somiglianze e differenze e l'inizio di una strategia per utilizzarle insieme, che ritengo sia un'idea interessante.
Wicket è principalmente una tecnologia lato server con un supporto Ajax integrato e ganci per il cablaggio in più Ajax. Non traduce Java in JavaScript come GWT. Mantiene lo stato sul lato server dove GWT mantiene lo stato sul client.
Entrambi sono basati sui componenti e per me hanno qualcosa del sentimento di sviluppo di Swing (sebbene Wicket non sembri avere la sensazione di essere Swing almeno di un altro rispondente).
Wicket è un framework basato su server. È molto più simile a JSf che a GWT. GWT è concettualmente simile a Swing, sono uno sviluppatore ex-swing, è molto facile migrare da swing a gwt. Ma non posso dire le stesse cose per Wicket o JSF ..
ho utilizzato sia GWT (1.xe 2.x) e Wicket (1.4, 1.5) su un grande progetto da diversi anni, ed entrambi i quadri hanno i loro vantaggi e svantaggi. Entrambi sono belli e piacevoli, se vengono utilizzati per quello che sono stati progettati per. Ma puoi prendere il meglio di entrambi dal mescolandoli insieme allo facilmente.
Wicket è veramente bello e potente per i siti web CRUD, con una buona separazione tra la struttura della pagina (HTML) e il codice Java. Finché non hai bisogno di potenti funzionalità client, sta facendo molto bene il suo lavoro, al premio di essere un po 'prolisso: ma è il premio da pagare per essere fortemente digitato: non c'è "magia"; refactoring e componentization funziona come un fascino. Per i progetti di grandi dimensioni può essere facilmente disaccoppiato ed è ben progettato per lavorare con grandi squadre: le persone possono concentrarsi sulla fornitura di un bel set di componenti di base, altro sul livello di presentazione, ecc ... L'unico svantaggio è per complesso comportamento sul lato client, è ancora necessario il master Javascript e può facilmente diventare piuttosto complesso da mescolare Wicket e Javascript da soli.
GWT è bello quando si ha realmente bisogno ricca di comportamento funzionalità sul vostro client (GMail-come l'applicazione). Il problema principale con GWT è che sembra troppo bello sulla carta (il paradigma "tutto in java"), ma non soddisfa le sue promesse.It non scala bene: GWT è utile per piccoli moduli che forniscono un piccolo insieme di funzionalità, non per applicazioni di grandi dimensioni. Il ciclo Code/Compile/Debug è piuttosto lungo e quando la dimensione del modulo diventa troppo grande diventa un peso. Inoltre, non supporta team di grandi dimensioni che lavorano contemporaneamente sullo stesso modulo.
Per riassumere, vorrei suggerire la gente a dover scegliere:
Scusa ma non sono affatto d'accordo sul fatto che la posizione di esso non si adatta bene. Avevamo un'applicazione molto grande e non avevamo problemi di ridimensionamento, oltre 1200 pagine dinamiche. Abbiamo utilizzato il pattern MVP e utilizzato GWT.runAsync per il caricamento veloce. Ho usato anche wicket e sembra più un quadro accartocciato di GWT. Cose come getModel e getOriginalModel sono fastidiose accoppiate con l'incapacità di lavorare semplicemente con il DOM è ciò che mi ha veramente sconvolto di Wicket. IMHO Vaadin sarebbe una scelta migliore di Wicket dal momento che 7.0 offre il meglio di entrambi i mondi, ma rimarrò con GWT. –
Quello che sto dicendo è che un modulo GWT ** ** non scala bene. Di per sé, GWT può scalare moltiplicando il numero di moduli, se si mantiene vincolata la dimensione del modulo. Ma confermo che avere dimensioni del modulo GWT troppo grandi è davvero doloroso per ragioni sia tecniche che umane. Btw non vedo cosa sia Wicket 'getOriginalModel()'? –
Perché la dimensione del modulo è dolorosa? La modalità Super Dev elimina la necessità di compilare tutto durante lo sviluppo e anche la modalità di sviluppo precedente era perfetta per questo. Se la dimensione del modulo è dolorosa per i tempi di download, ci sono molte opzioni per ridurre le dimensioni del download. Se GWT è adatto all'app GMAIL mobile (Android e iOS), penso che possiamo concludere che è in grado di gestire applicazioni complesse di grandi dimensioni. [In che modo Google Multi-Platform In Inbox] (http://www.i-programmer.info/news/83-mobliephone/8010-how-google-does-multi-platform-in-inbox.html) –
Sono trascorsi 6 anni da quando questo thread era attivo e GWT ha quasi ristagnato. Wicket sembra essere molto più attivamente sviluppato e supportato. Qualcuno ha opinioni più recenti su Wicket o altre opzioni?
Wicket è un framework server. Permette di creare html di cui hai bisogno. È possibile la separazione dei ruoli nel progetto. (Web design-> html/css-> java).
Se si considera di utilizzare GWT per il proprio progetto, il web designer probabilmente non è necessario.
GWT genera javascript. La maggior parte della logica può essere eseguita dal lato del browser. GWT migliore per l'applicazione scalabile.
Ciao, perché 'GWT è migliore per l'applicazione scalabile'? –
Con GWT è facile spostare la logica nel browser. Ciò richiede più potenza di calcolo per il client, ma meno potenza di calcolo per il server. Con GWT è possibile memorizzare i file js statici. – Dmitry
In alcuni casi, è possibile creare un'applicazione completamente da file js statici. La migliore condizione per il ridimensionamento. – Dmitry
duplicato: http://stackoverflow.com/questions/3569402/wicket-vs-gwt-advice-needed – Karussell