14

Searching for a web framework practicable for my few critical requirements in a new Java EE 6 project, I read here the now many threads on this topic, and I finally could reduce the number of envisioned frameworks to JSF 2.0, Wicket 1.4 (among the component-based) and SpringMVC 3 (among the actions-based).

Concerning these frameworks, I'll need some advice if and maybe how the following requirements are realizable:

  1. Preferably separated designer/coder workflow, so that designers -- optimally -- can independly elaborate their HTML, CSS, JS/jQuery files with their favored tools like Dreamweaver.

  2. Easy integration of the many existing (fancy and animated) jQuery components, such as this Sliding Login Panel (a demo can be seen here). Thus, the requirement actually is easy integration of exiting HTML+CSS+jQuery code AND ALSO:

  3. For an ui component tree, a sync mechanism to synchronize the view state dynamically changed on the client side (via JS/jQuery) with the corresponding view state on the server.

    I guess I'll need that. E.g., think of the above "Sliding Login Panel" having an 'open' or 'closed' changeable on the client side via JS. Its initial state is programmed to be 'closed', and the user decides client-side to always maintain it open. Now, when the user navigates somewhere and comes back to this view again, the login panel state is unintented 'closed' instead of 'opened' (as this is its initial state and no dynamic state updates occurred server side).

    Thus, a sync mechanism will be needed, right???

  4. Optimally externalized (somewhere centralized) navigation rules for
    (a) arbitrary inter-page navigation (static nav rules), and
    (b) "wizard-like" navigation (dynamic nav rules dynamically determined from current state/outcome).

  5. A good performance (load time, server memory comsumption, experienced responsiveness, etc.).

The obvious questions are:

  1. Which of these reqs are (well) supported by JSF2, Wicket and Spring MVC3 and which not?

  2. Generally, with this reqs -- and as I'm still unsure with the technical aspects/consequences: Which framework type (component- vs. action-based) should be chosen in that case (i.e., which critical decision aspects or "rules of thumb" should be kept in mind)?


Thank you very much for your advice and help.
Martin

Martin
  • 151
  • 1
  • 6

2 Answers2

12

JSF:

  1. In the template language of JSF (Facelets) this is easy. You just write regular HTML and only add the jsfc attribute for the dynamic parts. See the wikipedia article for a quick example: http://en.wikipedia.org/wiki/Facelets
  2. Using JSF's composite components this is really easy. Just put your jquery stuff in an .xhtml file, add a small header and it's reusable as a component everywhere. Many jquery based components are also directly available using PrimeFaces
  3. JSF excels in this sync mechanism. Synching happens via a well defined and easy to grasp number of steps. Basically, this sync mechanism is more or less the prime reason for using JSF instead of directly writing jquery.
  4. JSF has exactly this and it's even called exactly that navigation rules. They are a powerful mechanism to define navigation in an external .xml file. A navigation rule can be defined based on logical outcomes and/or actions taking place on specific pages. They can be forward or redirect based, with or without extra parameters.
  5. JSF overal performs really well. It keeps (saves) state, so this costs you some memory, but it's smart enough to only partially save this (values differing from their original values). You can furthermore decide to store this state on the client or the server. Because of the very convenient view scope, small amounts of data used by your backing logic can very easily be cached between requests. This saves you from hitting the DB after every request and can greatly improve performance.

One of the areas where JSF really shines is its component model. It's very easy to compose components yourself via its composite component concept. You can also create components in Java, which is a bit more involved but still absolutely not difficult.

Because JSF's component model is standardized and very clearly documented, many, many third parties provide ready to use component libraries. E.g. RichFaces, Primefaces, OpenFaces, IceFaces, Trinidad... the list is nearly endless.

Some extra note about the performance. In comparing any of three web frameworks you mention the difference is negligible, and as a rule of thumb the web framework is not where the majority of time is spend when processing a request. This is almost always in the Database and in IO.

The web framework can help by making it easy to prevent going to the DB, but even if web framework A is 10x faster in synthetic tests that only hit the web layer than framework B, then in practice you would barely notice this if only 5% of a request's time is spend in that framework.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
  • Arjan, thank you too for your help on JSF2. Like for the Wicket "sub-thread", point 3 is still unclear to me. Could you explain further how this synchronization works in JSF2, or at least point me to a code example, please? ..Again, the goal is to implement a HTML+CSS+jQuery comp, let it react on events on the client, and notify the server-side part about any state changes dynamically occurred on the client. What will I have to do in this respect for my self-developed components??? Thank you very much. – Martin Mar 28 '11 at 09:49
  • @all: Could anyone deliver a brief clarification of point 3 (or any respective code examples), please? This would help me a lot at the moment. Thank you a lot in advance. – Martin Mar 30 '11 at 15:56
  • 1
    The sync process is what the JSF "life-cycle" is about. There's quite a lot of info about that available, but in short after a postback it restores the component tree, applies the (raw) request values to the components, performs conversion and validation and then updates the model. There are two phases after this which are invoke application (call any logic) and finally a re-rendering of the view is triggered. For your 'synching' question especially "apply request values", "perform validation" and "update model" is relevant. These all insure values from the client are correctly transferred. – Arjan Tijms Mar 30 '11 at 18:57
11

Wicket:

  1. Preferably separated designer/coder workflow: possible due to the use of standard HTML and CSS. Designers edit the HTML, developers the Java. In the HTML there are only some markers (wicket:id attributes) to define where the dynamic components will be.
  2. Easy integration of jQuery: use WiQuery, which integrates JQuery components with Wicket. Using WiQuery you can integrate also other JQuery components, which can be contributed back (WiQuery is open source).
  3. For an ui component tree, a sync mechanism [..]: Wicket and WiQuery will handle that for you in most cases. Wicket is stateful on the server side and can handle refreshes of parts of the page for you (built in).
  4. Optimally externalized (somewhere centralized) navigation rules: Dynamic switching for Wizards is easy (it's just Java). Links just point to the Page class you want to show, switching to that page when clicked is handled for you.
  5. A good performance: This completely depends on your use case. Wicket can be clustered and scaled, so for 99% of the use cases you have 'a good performance'.

Some general remarks: I really love the component model of Wicket. It is very easy to write your own components and behaviors. The object oriented model of Wicket is really powerful.

Daan
  • 9,984
  • 2
  • 30
  • 36
  • 1
    Daan, thanks a lot for your help. By now, Wicket seems to have (a) the cleanest designer/coder workflow separation, and (b) an intuitive prog. model that obviously makes fun (as often heard now). Ad 3: [=client-to-server sync mechanism] As I still can't imagine how this really works, could you please elaborate further on the notification from client to server, or provide me with an example, please? ...I mean, having a HTML+CSS+JS component reacting at 'onclick' event via a JS func call, I suppose I'll need to decorate this JS func with some notify-the-server ajax behavior, won't I? – Martin Mar 28 '11 at 09:14
  • For the most part, you can use Wicket directly without writing custom javascript. Add an Ajax Event behavior http://wicket.apache.org/apidocs/1.4/org/apache/wicket/ajax/AjaxEventBehavior.html and start typing Java in the onEvent method. Wicket handles the rest. – Daan Mar 28 '11 at 09:25
  • For advanced stuff: every behavior also has a URL, which you can call from your own code. Through this you can communicate with the server side to manage state. Search for "getCallbackUrl wicket" to find more information. – Daan Mar 28 '11 at 09:27
  • Btw., Wicket's "downsides" could be (please correct me if I'm wrong): 1. Lesser num of prof. component libs compared to JSF2. 2. Wicket pages (visited via "cwiki.apache.org/WICKET/websites-based-on-wicket.html") seem to use fewer animated components (slide in/out panels, re-positionable and collapsible panels, lightboxes, dnd entry reordering, ...). Is it because of fewer comp availability or because they're more difficult to develop? Do you have some links to comp libs with showcases (comparable to PrimeFaces, RichFaces)? – Martin Mar 28 '11 at 09:29
  • Check for example the WiQuery demo's: http://wiquery-plugins-demo.appspot.com/demo/ and http://code.google.com/p/wiquery-demos/ I think it has more to do with designers than with the framework support. Wicket supports it, but if it's not designed right, you get developers reverting to the 'simpler' panel replaces. – Daan Mar 28 '11 at 10:06
  • Dear Daan: -- a little bit retarded, but -- thank you very much for your explanation of point 3 and the provided component libary links. – Martin Mar 30 '11 at 15:52