Tuesday, August 14, 2007

[Tech] Wicked Wicket

In the last years, the "market" of Web-frameworks was probably the most active one. I know hardly any other domain, where we can find such a number of different frameworks and tools. There are probable hundreds of different web-frameworks out there; just the Apache Software Foundation has: Struts, Tapestry, Cocoon, Wicket, Turbine (? never knew what this is good for), myFaces. So about 6, if I have not forgotten anything, plus a wide range of subprojects dealing with specific problems or providing taglibs or components.

So what to choose?

Actually it seems, that there are three streams of framwork concepts:
  • The "traditional" ones based on JSP (or PHP alike), HTML; i.e., more or less extending JSP like Struts or building upon template engines like Velocity
  • Special-purpose frameworks like Cocoon, that have a stronger focus on XML processing or content management
  • Application-oriented frameworks like Google Web Toolkit or Apache Wicket.
I recently had a look at the "new kid on the block" Wicket, that is recently graduated from the Apache incubator:

The general idea of Wicket is to provide a very clean separation between html/css presentation layer and application logic. As a consequence each "webpage" is a duo of one html page and one Java class. The Java class looks a little bit like a Swing class, in the sense, that visual components are initialised and assembled like in a Swing project. One could create a text-box and put it into a form component for example.

However, the concrete visual appearence is controled by a html document aside, in which html code is used with wicket id-attributes that reference to the Java code. The consequence is, that the html code is pretty clean, there is actually no logic in it, and the complete logic in in Java classes. Wicket also abstracts from the Servlet session, so that the developer never needs to actually touch the "naked" Servlet API.

Additionally Wicket has a lot of additional features like a validation framework, support for authorisation and authentication and the like. Wicket is additionally very Java-oriented, meaning that there is hardly any (XML) based configuration required to get a Wicket application up and running.

That said, the documentation is currently problematic and rather "example-driven". Also the examples are not particularly well documented and partly difficult to understand. Also to website and wiki is rather confusing from my point of view.

To get started I suggest to check out:
  • First check the Homepage. Unfortunately information there is rather brief. Also the examples are only a small extract of the actually available examples
  • Download the recent Wicket distribution or get it from the SVN. IN the distribution you also find a large number (of hardly documented) examples
  • The Framework documentation is an index about documentation on the Wiki.
  • The Wicket Tutorial (Platinum Solutions)
  • Wicket Javadoc
  • Additionally I highly recommend the Maven 2 archetype from the Jetty group to get started. I explained that in a recent post.
  • Additionally Wicket in Action is on the way for the patient ones.
My first impression about Wicket is a quite good one, however there are issues, that make me a little bit doubtful: one thing is the fact, that Wicket keeps a quite "fat" session, which might make problems with scalability.

On the conceptional level however, I am not sure if I like the HTML/Java duo with each page. Somehow I feel it is odd when I write something like this (from the Wicket documentation):

Why do I have to write additionally a html document then, where these two components appear again like so

Quite redundant, isn't it? In the Java class I made already clear, that I want a form and a text-field, so just render it!

I see that this attempt gives a lot of freedom how to render webpages. I am not sure though, if the better strategy in many cases might be to stick to the Swing concept of "Layout Managers". I.e. to refer to the example before: A layout manager (that I can select and customise) decides how the components are arranged on the page. As far as I see it, this is the strategy of the Google Web-toolkit. This approach avoids the beforementioned redundancy by also providing a clean separation between logic and presentation layer.

Comments anyone?



Unknown said...

I think that more and more people getting a chance to look at Wicket is a good thing for developers; for me, this is a very nice to use framework for building high quality web-applications and it encourages good OO practices. Have a play with building custom components by extending the ones that come "in the box", and reusing them with no effort at all ... very neat! Markup-inheritance is worth a mention too, even in a short appraisal, as I find it rather smart and in the spirit of Wicket, as well as the many other very powerful and easy to use features you will no doubt be coming across in the next episode of your evaluation.
I think that when you have a bit more time, you will see that there are indeed many reasons why Wicket scales very well (I am not sure at what level of load your experimental application had displayed memory(?) issues); assuming that you can up the RAM on your server (maybe to something like 512 mega bytes or 1GB), I expect that you will be able to service most classes of web-apps quite comfortably, even if you do not have time to find about all the clever and easy to use options the Wicket developers have thoughtfully built in (like detachable models, pluggable page mapping and eviction strategies etc) to cover many different use-cases your organisation may need to cater for.
The clean html/css+java code is indeed a bit new and takes a bit of getting used to (especially the default use of keeping java code and associated html files in the same package - but you can change this easily if you really can't get on with it; I quite like it now, especially for packaging up custom components). I find the clean html templates to be an ideal way of separating the java developers work from that of the html/css experts who can usethier favourite Dreamweaver-like tools to beautify the site without needing any special knowledge at all about Wicket, or the old-school special tag-libraries etc...
Anyway, I expect you will get some more useful feedback from the core developers who, along with the rest of the Wicket community are incredibly diligent at helping all-comers on the mailing-list and at addressing the few bugs that come up.
Thanks again for this first part of your look at Wicket and I hope which ever framework you end up using helps you enjoy your development and to deliver a top quality, well-designed and easy to reuse/maintain/extend solution.
Regards - Cemal

Johan C. said...

About the memory usage, i think this is always greatly exaggerated, when i look at real web applications (talking about web apps not web sites here, so complex apps) written in struts or the like and i look at the session usage it is most of the time way more then what wicket would do. Why? Adhoc memory usage by the developer hmm i have to get this over to the next request all that kind of stuff. And what happens if the next request isn't what the developer expects? Or the developer doesn't really clean up its mess? Those things happens yes the session keeps on growing. This will not happen in wicket wicket manages the session usage for you, in 1.3 there is only 1 active page in memory it will be swapped out if you go to the next. And if you use detachable models then the memory usage is very low.

the last few weeks wicket is optimized even further, we have been able to drill down the memory usage of an average page between 10% to 25%.

If you have a really complex app with complex pages then yes your pages could be between 150-200kb but only 1 of them is in memory so if we calculate with 200kb then in a heap of 500MB, which is nowadays very low end, could hold 2500 users. Ofcourse you also need heap for the rest of the system like hibernate and request handling and that will also generate a lot of garbage. But wicket is really optimized what a request cost, string creation and char[] copying is minimized as much as possible.

About your comment about having to have a new Form() and the form tag in html so on both sides. This is because of 1 thing. Layout the html is the layout code of the java code. If you didn't have that then java code would be even more verbose. Because you would call things like


and you name it. Then we have to map that to css. And we have to keep up with the css so support pretty much ever kind of tag there is. Why would we do that because there are great html design applications out there!

Anonymous said...

"Just Render It?" How is that supposed work? How should Wicket know where to render the field and what attributes should it have? Wicket puts you in control of the markup and that is intentional.

Alexander Schatten said...

I was actually refering to a strategy that is used by systems like Swing or Google Web Toolkit.

For me personally it seems more natural to just define the components in Java (like in Swing or GWT) and the framework should do the rendering according to layout-components.

I see no fundamental problem with this approach; you can actually fine tune a lot by selecting and combining proper layout managers.

This was the strategy I was refering to.

Igor Vaynberg said...

layout managers work fine, until your designer says he wants a div with this class here, and an img there, and another span here. and all those just to make the html layout how he wants it, no functional requirement. then you end up tweaking your layout managers and end up with a mess, or worse you end up defining stuff in code that is there only for the look and feel. nasty imho. yes wicket has some overhead for simple cases like you have, but how often do you have a form with a nested input without a bunch of divs with css mumbojumbo in between?

Unknown said...

Wow... "the framework should do the rendering according to layout-components"- that doesn't leave much room for custom rendering based on individual business requirements, now does it?

I would much rather have control over this aspect so that I can change layout on an add-needed basis! Isn't that the whole purpose of the MVC model? If Wicket was to do as you suggested it would be more like a MC framework with no application level control over the view!

Alexander Schatten said...

Ok, to use a quote from Linus Thorvalds: "I have strong opinions" ;-)

So, I expose myself and claim, that the layout manager approach is the superior approach. I think that can be clearly seen with the success and simplicity of GWT.

One main reason from my point of view is, that simple things should be simple to make, as I do not need to "double" the effort (with all maintenance consequences) as I have written about Wicket.

Having said that, I understand, that sometimes more flexibility is needen, but I wonder if it would not be possible to add the flexibility by using specific layout managers (comparable to the xy layout in Swing; more oriented towards HTML and CSS in that case of course) is these certain cases?!

Unknown said...

Regarding the use of layout managers in Wicket (as you seem to be suggesting) ...
that would just mean having to reinvent some way of specifying the equivalent to html & css (structure and presentation) in your java code, and what's worse, you would polute your java code with layout/look instructions (that would be more appropriately declaratively specified, perhaps with html & css ;-) and, importantly, you will have to change application-code, rebuild etc... just to skin your app, for example. So, I still don't get why you think layout managers would help.
Regards - Cemal

Igor Vaynberg said...

Take a look at the applications that use layout managers, the majority of them tend to look the same - which is great for desktop apps. But, webapps tend to have very different look and feels - exactly because they use html and css, which is a much richer way to describe UIs and allows companies to brand their applications better. Of course you can also make a counter argument for consistency here...

Take a look at WPF which is what windows is moving to, it is closer to html+css then to layout managers. This is just my opinion of course, but then again I had a terrible experience trying to write a web UI with layout managers before...

An interesting thing is that you can actually implement layout managers in wicket if you wanted to, but none of our users have expressed interest in doing this. So I can assert that this maintenance problem you are referring to is a non-issue for our users...