Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I have gathered some experience on this topic, as I started to program on a new project in November. The project is in a late stage now.</p> <p>For me, the following design guidelines were important:</p> <ul> <li>Use a modern technology stack that is both fun to use and will be in general use in future.</li> <li>Reduce the number of project artifacts - use annotations/Java code where it makes sense, omit XML.</li> <li>Use frameworks that are open-source</li> <li>Have an active community</li> <li>Are not alpha stage</li> <li>Are lightweight</li> <li>Avoid duplication of concepts</li> <li>I can explain the concepts in it to my two fellow developers, who - despite being good programmers - have never used <a href="http://en.wikipedia.org/wiki/Dependency_injection" rel="nofollow noreferrer">dependency injection</a> (DI) or web frameworks.</li> <li>Can serve as a techological basis for future projects</li> </ul> <p><a href="http://en.wikipedia.org/wiki/Google_Guice" rel="nofollow noreferrer">Google Guice</a> as a DI container was an obvious choice - clearly the most well-thought DI contianer, with brilliant developers and a good community. It fulfills all the bullet points mentioned above.</p> <p>So I set up my basic techology stack. Started with Guice, added <a href="http://en.wikipedia.org/wiki/Hibernate_%28Java%29" rel="nofollow noreferrer">Hibernate</a> for persistence (along with <a href="http://www.wideplay.com/guicewebextensions" rel="nofollow noreferrer">warp-persist</a> and <a href="http://www.wideplay.com/warp%3A%3Aservlet" rel="nofollow noreferrer">warp-servlet</a>). Then I wrote some basic <a href="http://en.wikipedia.org/wiki/Data_access_object" rel="nofollow noreferrer">DAO</a> that selects something.</p> <p>Then I tried to do the following: added a different web framework on top of that.</p> <ul> <li><a href="http://www.w3schools.com/xsl/" rel="nofollow noreferrer">XSLT</a> with <a href="http://xstream.codehaus.org" rel="nofollow noreferrer">xStream</a> using regular HTTP servlets</li> <li><a href="http://myfaces.apache.org" rel="nofollow noreferrer">JSF- MyFaces</a></li> <li><a href="http://wicket.apache.org/" rel="nofollow noreferrer">Apache Wicket</a></li> <li><a href="http://code.google.com/p/warp-core/" rel="nofollow noreferrer">warp-widgets</a></li> </ul> <p>I created a simple page with a table, populated by the DAO, headers and a textfield with all four frameworks.</p> <p>These were my findings when comparing the four frameworks.</p> <p>XSLT and XStream is kind of a hardcore-approach. It's not really a framework, but a viable completely stateless techology for high-performance applications. This was by far the fastest way of serving the test page. In debug mode, 3&nbsp;ms on localhost versus about 30-50&nbsp;ms with the other framworks. </p> <p>Guice integration was relatively smooth and good using warp-servlet which enabled me to inject into servlets and injects httprequest, httpresponse, session in other objects, without passing them around. Disadvantages: no community at all, since I am the only person who would consider this stack. - no ready-to-use components. </p> <p>Then I took a look at JSF and Guice: it is of course possible to put the injector in the servlet context and use guice as a service locator. With the straightforward approach it's impossible to inject backing beans somewhere else. Using a custom variable resolver solves this partially, but then you lose all <a href="http://en.wikipedia.org/wiki/Integrated_development_environment" rel="nofollow noreferrer">IDE</a> integration in your JSF files plus you will have to use ugly <a href="http://en.wikipedia.org/wiki/Fully_qualified_name" rel="nofollow noreferrer">FQN</a> for your backing beans, or build a string->Guice key mapping somewhere. Both are ugly as:</p> <ul> <li>Advantages: good community, many developers in the job market (no criteria for me). You won't get fired for chosing JSF if something goes wrong.</li> <li>Disadvantages: brings its own <a href="http://en.wikipedia.org/wiki/Inversion_of_control" rel="nofollow noreferrer">Inversion of control</a> (IoC) mechanism which clashes conceptually with guice.</li> </ul> <p>warp-widgets: I created my simple example using this for fun; it's early alpha stage. It was nice to use and its components are easy to implement and reuse by myself. It aims to provide typesafe HTML with perfect Guice integration. Since it looked like it had only one active developer back then, who is now propably working on Guice 2.0, I would say the community is nearly non-existent. It worked like a charm, was reasonably fast, but I would have been alpha tester. That was simply too risky for me to consider it for a commercial project. </p> <p>Apache Wicket: this project first suprised me with wicket-ioc and wicket-guice coming together in the core download. Constructor injection in web pages is not possible, only setter+field. Injection in Wicket web pages is easy, just add <code>@Inject</code> to the fields you want to fill - but you're not supposed to understand <a href="http://cwiki.apache.org/WICKET/guice-integration-pitfall.html" rel="nofollow noreferrer">how it works in background</a>. Tricky stuff happening. Injection of web pages is theoretically possible - but I have not used it once, since this makes it impossible to use mounted URLs, plus it will mess with the persisted/serialized state. Injected members of classes are dealt transparently with web page serialisation, which is necessary for enabling browser-back support. Wicket uses zero external artifacts - just a little configuration of the <a href="http://en.wiktionary.org/wiki/configuration" rel="nofollow noreferrer">URLs</a> in a application class. So all configuration is done in Java - which fits the Guice model well. Clear seperation of HTML and Java. It's open-source just like the majority of the components that are numerous and of good quality. It's around since 2005(?) and is a top-level Apache project. Although it's a feature-rich framework, its <a href="http://en.wikipedia.org/wiki/Application_programming_interface" rel="nofollow noreferrer">API</a> is reasonable compact (all core classes fit in a single <a href="http://en.wikipedia.org/wiki/JPEG" rel="nofollow noreferrer">JPEG</a> on my screen). Unlike others, it does not bring a IoC mechanism of its own, but rather thinks of IoC as a service that can be provided by <a href="http://en.wikipedia.org/wiki/Spring_Framework" rel="nofollow noreferrer">Spring Framework</a>, Guice, etc. and that philosophy makes it superior w.r.t. Guice integration. Did I mention really smart and easy Ajax support?</p> <p>Frameworks not deeply evaluated: tapestry5 - brings its own IoC. <a href="http://en.wikipedia.org/wiki/JBoss_Seam" rel="nofollow noreferrer">Seam</a>: not a framework on its own, but a meta-framwwork which normally comines Spring, JSF. Hibernate. (Though Spring may theoretically be replaced by Guice.)</p> <p>Summary: of the evaluated framworks, <strong>Apache Wicket was the clear winner</strong> - with respect to Guice integration + all other criteria mentioned.</p> <p>Besides us two, some other people <a href="http://static.raibledesigns.com/repository/presentations/ComparingJavaWebFrameworks-ApacheConUS2007.pdf" rel="nofollow noreferrer">have had this problem before</a>.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload