Wicket o play framework?

Question

Sono totalmente nuovo per lo sviluppo web Java e vorrei scegliere una buona Java framework web per imparare. Ho trovato alcuni buoni echi relativa al quadro Apache Wicket e il play framework . Ho deciso di andare per uno dei 'em; ma ho bisogno di scegliere; -)

Quindi, cosa scegliere e perché?

Modifica

I miei requisiti:

• Ho avuto una buona esperienza di sviluppo con Django, quindi un quadro simile sarebbe fantastico,
• Ho bisogno di un quadro che può interagire con altri principali chicche Java (librerie, strumenti .etc) in modo da poter approfittare di ciò che Java fa davvero offrire.

Answer 1

Wicket and Play sono due tipi molto diversi di quadri.

Il gioco è un framework MVC che probabilmente sentirete familiarità con provenienti da Django. Come Django, offre più di solo le parti web e fornisce un quadro ORM JPA basato, ponteggi strumenti e probabilmente molto di più (non ho alcuna esperienza pratica con esso). Hanno un grande tutorial sul loro sito, e probabilmente vedrete il Django somiglianze lì.

Wicket è un framework orientato componente (come JSF e Tapestry) e si concentra molto sul orientato agli oggetti di design. E 'anche MVC, di per sé, ma le pagine sono di solito costruiti componendo componenti indipendenti e riutilizzabili (View Controller e, Modelli pluggable). Questi componenti possono essere estese per successione standard composizione e marcatura è molto pulito separati dal codice e facilmente modificati.

Wicket in grado di gestire i callback di eventi e lo stato automaticamente, in modo che non si sono di pensare a tutti gli URL, non importa quanto complessa la pagina è. Un esempio veloce per un pulsante cliccabile che va un via quando viene cliccato (molto utile):

  // In a page constructor
  add(new Link("link") {
        public void onClick() {
          setVisible(false);
        }
    });

Ci tengo a sottolineare che non c'è bisogno di usare lo stato lato server, e che è del tutto possibile utilizzare Wicket come un framework MVC "normale" se si vuole (e sì, è facile da ottenere abbastanza gli URL) .

Il progetto Wicket si concentra solo sul web framework di base e non ci sono "sottigliezze" extra come il supporto ORM speciale o impalcature. Personalmente sono d'accordo con la filosofia del progetto Wicket qui, ma per i nuovi sviluppatori che vengono al quadro, facendo cose "semplici" come ad esempio una tabella ordinabile e paginabile può essere un po 'scoraggiante come componenti predefiniti sono un po' scarse. La curva di apprendimento e la produttività per Wicket può essere un po 'ripida, ma il lato positivo è che una volta che hai fatto componenti (e "comportamenti" - storia più lunga) che si adattano alle vostre esigenze, sono estremamente riutilizzabili.

Anche se io personalmente amo Wicket, ho la sensazione che probabilmente sarà meglio fuori con Play. La tua domanda indica che si vuole un "Django" con accesso a librerie Java, e in quel caso penso Play (o qualche altro Java MVC) è la scelta sicura. D'altra parte, forse hai utilizzato Django, perché non sapevi quanto incredibilmente potente Wicket è. ;.) Se si dà un po 'di informazioni sul vostro progetto, saremo in grado di dare una risposta più qualificato

Come un lato nodi: come un gioco non è molto tradizionale (almeno per ora), mi piacerebbe anche considerare Grails che ha un forte sostegno commerciale e ancor più out-of-the-box moduli.

Answer 2

Play! è stato progettato per essere comodo per gli sviluppatori provenienti da linguaggi di scripting come Python e PHP. Esso fornisce i propri script di sistema di costruzione e di gestione, un po 'come Rails o Django sarebbe. Esistenti strumenti di generazione e le infrastrutture (come i repository Maven comunemente usati per la gestione delle dipendenze in Java-terra) non si integrano bene con Play.

Wicket sarà più comodo per gli sviluppatori provenienti dallo sviluppo del desktop in Java. Non fornisce utensili speciali, in modo che sarà più facile da integrare in uno specifico strumento di build se avete una preferenza (e ci sono molti strumenti di compilazione che forniscono le cose come dipendenza automatizzato di recupero disponibili nell'ecosistema Java.)

Quindi c'è un po 'di differenza tra le due opzioni :) Se si riesce a capire che l'esperienza avrebbe beneficio più, la decisione dovrebbe essere abbastanza chiaro da lì.

Answer 3

Se il sistema è solo per Web tier, Play! quadro è molto adatto. But, se i modelli di dati non sono solo per il web, forse exported as REST by Spring with CXF, e consumati dalla GWT o altri servizi web, e si desidera assicurarsi che gli stati coerenti con livello Web, Wicket (con Primavera / Hibernate) è una scelta buona.

Una cosa che non mi sento così bene con Play! è il meccanismo di cache. Bisogna nominare manualmente / inserto / recuperare / invalidate / spurgo della cache. Questo renderà l'intera architettura errori. Mentre wicket con molla / JPA (ibernazione) / EHCache (o di altri fornitori), è possibile definire la cache coerente / dao strato per strato superiore (web / REST ...), che non imporrà incongruenze statali.

Un altro vantaggio con wicket è che ha un supporto integrato AJAX sostenuta da Java. Anche se gli stati di questi AJAX sono mantenute nel lato server (e forse un po 'lenta), se non si vuole imparare JavaScript, è ancora possibile costruire una pagina AJAX 'non-così-male'.

Con Play! , Se non sai di JS, e non si vuole imparare, non vogliono manipolare DOM ingombranti, si può costruire solo un sito 'media'. OTOH, se siete abili con JS / jQuery, è possibile scegliere Play! .

Answer 4

sto usando PLAY! un sacco e hanno utilizzato Wicket per un po 'di valutazione. La mia esperienza è che si deve scrivere un codice molto di più per ottenere lo stesso lavoro fatto con Wicket. Hai più "indiretto" con Wicket. Io personalmente preferisco il codice che ha il meno possibile "cerimonia" e che è facile da seguire.

Il Play! gli architetti sono anche l'aggiunta del supporto per giocare Scala !, che credo sia una grande idea, dal momento che Scala è completamente interoperabile con il codice di Java e le librerie, ma di gran lunga più avanzato quindi Java.