One thing that does help with keeping the viewstate size down in JSF 2.0 is the so-called partial state saving. This only puts the delta changes in the viewstate, which can cause a massive reduction in size.

Regarding the URLs, I noticed that some Wicket sites like ov-chipkaart.nl also put “wicket:interface” in the URL and multiple colons, e.g.

https://www.ov-chipkaart.nl/?wicket:interface=:1:1:::

This looks worse than http://example.com/product/abc/.1.2

It seems to be a known problem: http://osdir.com/ml/users-wicket.apache.org/2011-05/msg00206.html

That probably reflects your style of program design. COBOL programmers also re-use code very rarely; their language makes doing so very difficult, and when COBOL programmers try more modern languages they often don’t appreciate what the newer modularization features can do for them.

The trend in programming languages is to increase support for code re-use, going from macros in Assembler and include files in COBOL, to functions and procedures with local variables in Pascal and C, to abstract data types with local functions in Modula-2 and Ada, to object-oriented code with implementation inheritance in languages such as Java. Of course, making intelligent use of each innovation requires a new set of rules and heuristics for program design (loose coupling, high internal cohesion, the Liskov substitution principle, etc.).

Most approaches to web programming make reuse of display code very difficult, so as with COBOL programmers, most web programmers don’t think to look for reuse opportunities. Likewise, just as all the variables in the typical COBOL program (in the WORKING STORAGE section of the DATA DIVISION) are global to all of the procedural code, in the typical web application all of a form’s data is in the HTTPRequest object — global to the entire front servlet. Re-use based on “include” files and template processing is like going back to the days of Assembler program macros again!

A framework such as Wicket gives you much better opportunities for reuse of display code, information hiding, loose coupling, etc., but as with the COBOL programmer who learns Java, the developer still has to learn to make use of object orientation when coding the display. (Former fat-client Swing developers may have the advantage here.)

Wicket users usually say its easy and hey, its component oriented. But one can create good software even outside the Wicket world. You can even create components. In all the cases I had to work with Wicket, I needed HTML/CSS/JavaScript skills. And components… well, are there so much Components I actually reuse? I had not too much of them.

getMarkupSettings().setStripWicketTags(true);

IMHO this should have been the default.

>Frank Silbermann says:
>But what if I _want_ to use Java?
According to what you wright what you want is 1:1 HybridJava.

Stateless controller-to-view/action-based frameworks only keep user input data client sided (temporary send to server when sending a request), where a Wicket page keeps most/all data (not just user input, but also view objects/data etc) server sided, and thus uses more memory. Processing user input data send from a client hardly uses CPU more than a request send from a client to Wicket. Unless you’re talking about viewstate data.

—

Clientside view state:
Like I already said, both client-sided and server-sided state have drawbacks. If every single click sends half a meg of data back, than there clearly is something wrong with the design of the webapp; wrong design decisions have been made. But that doesn’t imply that client sided viewstate cannot have any advantages in some scenario’s. What I like to see is a framework that offers both.

—
HIGH LEARNING CURVE:
Like I said, I like component based frameworks. So I understand why you hate those other MVC frameworks. I also agree that Wicket offers more, and thus there is more to learn.
But my point is that after I read the recommended Wicket book, I still didn’t have a clear picture in the way Wicket is architectured. This documentation aspect (and not just the API on it’s own) makes Wicket extra difficult.

—

Wicket URLS:
No, I don’t prefer 2000 char urls. What I do prefer, like I already said, are urls that don’t reveal any framework or technology. This makes the webapp more flexible to change from framework without loosing Search Engine indexed pages.
I had some cases where some unwanted redirects occurred on first page hits, where the post-redirect-get pattern isn’t needed. But maybe I should change the rendering strategy like you say.

—

HTML IS NOT THAT PURE:
Good point. IMO setRenderBodyOnly than should be enabled by default when using repeaters. I’ll change the post.

—

STATIC COMPONENT TREE
“You can argue that the atomic pieces inside the repeater, the panels, still contain predefined markup.”

That is exactly my point.
I see these options to make a complete dynamic tree:
-The combination of repeaters, panels in panels, and logic, and maybe fragments. When you create some generic panel that only contains either a repeater or a component, than you can create a tree which contains panels in repeaters in panels in repeaters in panels etc. But this is a hell to code, read and maintain.
-Skip components/objects, and just write HTML directly. Which can be a lot easier than the first option, but it can also increases maintenance, and it skips the Wicket API.
-Use IMarkupResourceStreamProvider to change the Markup stream. Which sounds difficult to me (I’m not a Wicket expert), and feels more like hacking it yourself to accomplish it.
-Use some code written by someone else that supports it. Like Wicket Webbeans if you need to make HTML forms based on beans.

So my conclusion now is, a complete dynamic tree structure is possible, but hard.

“Show me another Java based component framework where you can swap components so freely?”

Google Web Toolkit (GWT). In GWT it’s easy to create a complete full dynamic tree structure, because it doesn’t hav a dependency on predefined Markup. In GWT, you can do:
VerticalPanel mainPanel = new VerticalPanel(); RootPanel.get(“…”).add(mainPanel); Button b = new Button(“….”); mainPanel.add(b);
Without defining any HTML markup structure or placeholders upfront.
(GWT has other big drawbacks, but that’s a different story.)

—

VERY VERBOSE
Can you show/point where I can find some more info about the QueryModel approach? (I’m not a Wicket expert. I use LoadableDetachableModel because it is the best approach that I see that is described in the book Wicket in Action.) Anyway, QueryModel itself is an extra layer if you follow the DAO pattern.

It is a very commons practice to put all data access logic in DAOs, because of the Separation of Concerns principle. Putting any queries (like SQL, HQL or criteria API) in a Wicket WebPage subclass or Wicket component subclass violates the concept of using DAOs.

If you follow the principle, then you need DAOs. Those DAOs need to be called via Wicket code. The data the DAOs return, cannot be used directly in Wicket components, because in Wicket that causes everything to be serialized, and causes sessions to be blown up. In Wicket, models are needed as an intermediate layer. This intermediate layer is extra verbosity, but needed due to the way Wicket is architectured. (There are also frameworks that don’t require such an extra layer.)

—————————

@Craig
I have never worked with designers, but I’m wondering why a developer has to be directly involved in framework/Wicket mixed HTML markup. I would prefer to see it indirectly instead of directly, by letting the designer give you a 100% HTML/CSS (Without wicket ID’s and fragments), and that you (the developer) converts it to a Wicket mixed HTML markup. Than the designer doesn’t have a dependency on some particular framework markup. But I agree that if you let designers directly involve in framework mixed HTML markup, than Wicket is probably one of the most comfortable frameworks for designers.

“Ajax dead simple”, is something I see as a benefit of most component frameworks. It’s one of the reasons why I like component based frameworks.

My only comment is the fact that Wicket lets you work with designers (the creative types that know photoshop/dreamweaver) throughout your development process and into maintenance. Try that would JSF, JSP, Grails, etc… If you do, you better hope your designer knows how to code and not be reliant on his design tools (ie. hack some html, load in a browser(s), tweak, repeat).

I’d also add “makes AJAX dead simple”. You don’t have to touch JavaScript, the components take care of it.