This is a blog about strategies and tactics I have learned, mostly from my experience of playing 3D fighting games and reading classic strategy books. Oh... and Java.

Thursday, March 26, 2009

The top 8 reasons I don't use Wicket

A few months ago I knew I was going to make a hobby website. In preparation I decided to learn a new Java web framework. Wicket had a lot of hype around it in the #java channel so I figured I should give it a shot. Along the way, I created 2-3 work projects, 2 practice hobby projects and 2 open source libraries for it. All in all, I spent about 5 months using it and frankly, it was a terrible experience. This article will explain my complaints, but first, I will give you a little introduction to the framework.

In a typical web framework, you write a template that's more-or-less HTML, but with special code to make it dynamic. For example, here's how to print "Hello World" in php:


NOTE: I am NOT saying that PHP is better than Wicket. I'm just EXPLAINING how Wicket works compared to other frameworks and using PHP as an example of another framework.

<html>
<head>
<title>PHP Test</title>
</head>
<body>
<?php echo '<p>Hello World</p>'; ?>
</body>
</html>


In the <?php ?> tag, you specify what HTML will be generated. Wicket works in a different way. You mark the dynamic parts of your HTML with a special attribute and specify what it does in Java code. Here's the same example in Wicket:

<html>
<head>
<title>Wicket Test</title>
</head>
<body>
<p wicket:id="message">This is replaced</p>
</body>
</html>


And then in a Java class:

public class HelloWorldPage extends WebPage {
public HelloWorldPage() {
Label component = new Label("message", "Hello World!");
add(component);
}
}


By comparison the html template is simplified: You define the parts that are dynamic but you don't say what the dynamic parts will do. That's done entirely in the Java code. If you learn more about Wicket, you'll see that your Java code ends up looking similar to Swing code (Swing is Java's GUI API).

Before I go on to explain the top 8 reasons to NOT use Wicket, I want to say that there is one situation where I would still use it: If a large part of my webapp functioned like a wizard. Wicket makes it easy to keep track of state from page to page without persisting at each step. With a traditional framework, you have to manipulate the session or use hidden fields to accomplish this.

1. Documentation, documentation... documentation?
By far my biggest complaint about Wicket stems from problems with its documentation. Imagine this: You get stuck on an issue and have no idea why. First you search the official wiki. You try your hardest to find a section to answer your question but it doesn't seem to be there. On the other hand, it's so badly organized you may have just missed it. You guess it's not there and move on to the examples.

The examples can be useful, but there's a lot to be desired. Exercise: Visit http://www.wicketstuff.org/wicket13/ and try to find an example that shows you how to redirect to a different page after you submit a form. I had to ask in the IRC channel to figure out how to do that. It also doesn't help that there are two example pages. One is on the main site, and another (much more useful, I might add) that's on wicketstuff.org (but good luck finding these examples on the wicketstuff.org home page).

Lets say the examples didn't help so you move on to the Javadocs. No help there: The class in question and its methods are barely documented. Take a look at this gem: http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/SharedResources.html At least this time it's obvious the answer isn't there.

Time to move on to the mailing list archives. You discover that Wicket's mailing list is extremely active and is often the only source for answers. Here's the downside to that: 1) A mailing list is not the right environment to learn a framework. A mailing list is for situations where you more-or-less "get" the technology, but are unsure of a few things. 2) It's hard to find mailing list answers by Googling. Think about it, how often do people link to a mailing list threads? Almost never. That leads to poor page ranking and that means the answer to your question, even if it's there, is hard to find.

2. High learning curve
Even if the documentation was well written and complete, Wicket would still be harder to learn than most frameworks. Lets look at how to solve some basic problems using the example above:

How do hide a dynamic tag? component.setVisible(false). How do I dynamically add a class attribute to the tag? component.add(new SimpleAttributeModifier(“class”, “classValue”)); How do I dynamically add a CSS file to my template? webpage.add(HeaderContributor.forCss("/path/to/my.css"); Do you see the problem? It's subtle.

Knowing the answer to one of these does not help you in answering the others and each one of these questions requires you to deal with part 1. On the other hand, as soon as you learn how to write a conditional in PHP/JSP/ROR, you immediately know the answer to all of these questions and many more in the future.

Let's try an example together: How would you make a page's title dynamic in Wicket? Is it webPage.setTitle(String)? Nope, that doesn't exist. In fact, the word title isn't even mentioned in the javadoc. Ok, dead end #1. Perhaps it's webPage.add(new Title(...)); or something like that. Nope, there's no such thing as a Title class. In fact, the word Title isn't even part of any class in the javadoc. Dead end #2. That also rules out something like webPage.add(TitleContributor...); Dead end #3.

So, how the heck do you actually do this in wicket? The only answer I can find is webPage.add(new Label("wicketId", "dynamicTitle");. You add a Label to your page that attaches to your <title> tag and overwrites the text. Duh!

3. Different... not better, but different
In my 5 months with wicket, there was no indication that it was a time saver. Wicket seems more about making a webapp in a different way than in a productive way. Compared to a framework like Struts or Ruby on Rails, Wicket probably decreased my template code by 4x but increased my Java code by 4x. I ended up doing the same amount of work, just in a different place.

If you consider writing template code to be traumatic experience, perhaps you'll see this as a huge improvement. But, if you're like me, you'll think that a webframework should help you write less code. Writing less code has a lot of benefits. There's less to understand, less to maintain, less work to add a feature, etc.

Perhaps these time saving features exist and I overlooked them. Unfortunately, Wicket doesn't have an official list of, "Cool features that will save you tons of time" anywhere, so you'll likely have the same experience as me. But, I did read most of "Wicket In Action" (great book for learning Wicket, BTW), and it didn't change my impression.

4. Lacking 3rd party library support
Getting 3rd party libraries to work in Wicket is more annoying than other frameworks. By 3rd party libraries, I mean external tools that add content to your website that may or may not care about the programming language you use. Things like ReCaptcha to add a captcha to your site, the Facebook API for making a Facebook app, or Rome to add a RSS feed to your site. Fortunately, there are Wicket extensions for these examples (I made the first two), but unless you make your entire webapp from scratch, you're bound to run into others that aren't. With Wicket, getting these libs to work can be painful and confusing.

Lets look at ReCaptcha to see why. With ReCaptcha, you add a <script> tag to your webpage that refers to an external javascript file. When it loads, the script generates a captcha and an input field for you. When the user submits the page, you take the input and ask the ReCaptcha server, "User typed this, is that what was displayed?".

With most frameworks, this is an easy way to add a captcha to a website. With Wicket, it's a challenge. Since you didn't include this input in your template (remember, Wicket needs a wicket:id attribute on input fields too) and you didn't put add(new TextField("recaptchInput")); in your Java code, Wicket is unaware of the input. As a consequence, you can't leverage any framework features. This includes essentials like retrieving the value so you can pass it to the ReCaptcha server.

For those wondering "Why doesn't he just put it in his template and add the Java code?", that won't work: The ReCaptcha script would just generate another input field for you and cause the same problem.

What's the solution? You need to reach into the HttpServletRequest and extract the value by hand. Most frameworks, including Wicket, consider this a primitive way to get data from a user response. Yet, as far as I can tell, it's what you have to resort to.

5. Generate HTML or generate pain
Sometimes you want the server to generate something other than HTML. For example, you may want to generate Javascript or CSS. EG: var message = "dynamicString"; To make the string dynamic, the template would have to say var message = <span wicket:id="dynamicString">localized alert</span>; You have to do similar things in your CSS files to make them dynamic: .highlight { <span wicket:id="highlight">highlight style</span> }

Unless your editor speaks Wicket, this will drive it nuts. Not only will the dynamic bits be more verbose than a typical framework, they'll look more out of place. "Why is this HTML embedded in this CSS file?".



6. Easier to maintain?
One of Wicket's selling points is that it's far easier to maintain than other frameworks because you write most of your code in Java. I think that's debatable. Is 4x more Java code more maintainable (see part 3)? The code you write ends up looking like Swing code so unless you're very disciplined, you end up writing anonymous and inner classes all over the place that share instance variables with the parent class. Once that happens, it's a real chore to refactor them to outer classes.

If you put in the effort to avoid these pitfalls, your code may be more maintainable. But a framework is supposed to facilitate discipline, not put the burden on the developer. With Wicket I found myself thinking, "OK, how can I add that feature without it turning into a mess later?". I'd prefer to just focus on the feature itself. If I wanted to focus on proper discipline, I would've stuck with JSPs and Servlets in the first place. This goes back to the question, "What is this framework doing to make my life easier?"


7. The "Great for web designers" myth
Wicket is supposed to be nice for web designers because it doesn't use template code. You just put a wicket:id="something" on the HTML you want to be dynamic and replace it in your Java code. The end result is your HTML is perfectly understandable by a web designer who doesn't know the first thing about Java. While Wicket may be better than other frameworks in this respect, it still has problems.

For instance, Wicket has non-HTML tags for special functionality with names like <wicket:panel>, <wicket:child> and <wicket:extend>. These won't render correctly in a browser. If you research the last one, you'll see you must violate the "Don't Repeat Yourself" principle to get your pages to render outside the browser in a way that looks similar to its production code.

In general, Wicket is better than most frameworks in this respect. But, when you consider part 5, it can sometimes be worse than most.

8. Search Engine De-optimization
By default, the URLs Wicket uses look like this: http://www.startfound.com/?wicket:interface=:3:::: For a search engine, this is a problem for two reasons:
  1. This URL provides no semantic information
  2. This URL is only valid for that user's session.
This second point is really important: If google indexes http://www.startfound.com/?wicket:interface=:3::::, when users follow the link, they'll be taken to a "Page Expired" error page. It's not a great first impression. You could make your URL look pretty like this: http://www.startfound.com/home, but that requires using a Wicket concept called "bookmarkable URLs". Hopefully, the name is self explanatory but they bring with them a big downside.

There are Wicket classes that won't work with bookmarkable URLs. For example, if you want to use the Wicket "paginator" (think the bottom of Google search results), your URLs have to look ugly. So if you want pagination on your site with pretty URLs, you're going to have to write it yourself. And that goes for a lot of its other APIs.

Conclusion
There was a point while working on my hobby website that I was pulling my hair out dealing with these issues on a daily basis. Finally, I had enough and came to the conclusion that it was smarter to rewrite the whole thing from scratch in another framework.

I chose what I'd consider to be the exact opposite of Wicket: The Stripes Framework. During and since the rewrite, I couldn't be happier with my choice. When it comes to ease of use, quality documentation, simplicity and productivity, I've never worked with a better web framework. Let me state that I'm not affiliated with the Stripes framework, I'm just a huge fan. I have experience with Struts, Ruby on Rails, plain old JSPs and Servlets and, of course, Wicket, and the Stripes framework is by far the best web framework I've ever worked with.

One last note on Wicket: Of all those projects I created while learning it, there was one where I feel Wicket was the right choice (the whole thing was basically a Wizard). So in the end, I consider Wicket to be a hammer in my tool belt. Unfortunately, most jobs I come across require a screwdriver.

You can see my follow up blog post that compares Wicket and Stripes in depth here: http://www.assertinteresting.com/2009/03/why-i-prefer-stripes-over-wicket/

80 comments:

Eelco Hillenius said...

Too bad Wicket doesn't work for you. When it comes to documentation though, there are several books on Wicket (I wrote one of them), plenty of Java docs, examples, the IRC channel and one of the busiest mailing lists in open source land. I mean, how much more do you need to figure out your stuff? And for the record, there is an example that shows how to redirect to another page when in a form submit, and one single google would have given you the answer as well: setPage (how much more predictable can that be?).

Re maintainability. I agree you have to be careful for pitfalls, though even if you step into them, they are typically not huge problems. But Wicket does beat the crap out most other frameworks when it comes to maintainability simply because you can let loose all your Java tools on them for refactoring and code navigation. If you just want to get something up and running quickly, or if your site isn't terribly complicated, by all means consider other frameworks. But when you're building something complicated over a long time span where you can expect plenty of changes over time, Wicket is worth it's weight.

craiger said...

Open your non-wicket template file in an editor such as Dreamweaver and tell me how it looks :)

Wicket is, in my opinion, the only sane way to develop in a shop where there is a clear distinction between developer and designer. A designer can completely redesign a page if they want without "disturbing the code", that's a huge win.

rich said...

You're not really comparing like with like when you're comparing it against PHP. That's not exactly fair.

Try comparing it with Spring. That has masses of documentation and yet has a much greater barrier to entry.

I haven't found a better framework for Java web applications.

dsmith said...

Unlike the previous comments, I agree w/the author. Wicket in Action is one of few current books and it was very recently published.
And while I do like it, I just regard it as different not necessarily a framework to make me more productive.
Tapestry 5 is in the same boat when it comes to documentation (and it might just be the best framework out there), but that's another topic.

Boller said...

->craiger, that is not completly true. If the designer change the hierarchy of the wicket:id, I think the developer will be in trouble if no code change is done.

Eelco Hillenius said...

"->craiger, that is not completly true. If the designer change the hierarchy of the wicket:id, I think the developer will be in trouble if no code change is done."

True. But the page or component will simply fail hard. Unlike the many situations I've seen with apps where scripting is used, and where the designer decides to do little tweaks without understanding it fully, and messes up functionality in a subtle way. I'm not making this up... I've actually seen this happen with loops and conditionals and stuff that for me way back when it was one of the reasons to try to get rid of scripting.

Gyowanny said...

Excelent post.

I agree with you about those reasons. Try the ZK framework (http://www.zkoss.org) and you´ll get surprised with it.
If you have any questions please feel free to contact me: gyowanny@gmail.com

Cheers

Gyo

florin said...

Please don't flame this:

While wicket does a great job at component-izing your web app, I found the Apache Click framework to be the best answer for all my web app needs. Give it a try. It is component based also yet uses velocity, jsp or freemarker to hook up the java code to the page.

$form will render the entire form on the page.

$form.fields.firstName will allow you to layout the form manually.

form.setAction(..) will pick up the submit event from the page and hook it up to the onSubmit() method declared on the backing java code.

This is all you need to know to get started in one day.

tieTYT said...

rich,

Although it may not have been as explicit, I was comparing Wicket to Struts, Stripes and Ruby on Rails, too.

Casper Bang said...

Wow. Very different than my own experiences, at least with Wicket you are not required (as with JSF/Facelets) to mess with various type-unsafe tag libraries and tie it all together with even less type-safe EL.

Each man has his own opinion I guess!

tieTYT said...

Casper Bang: aren't tag libs type safe? Search for the word "type" on this page: http://www.oracle.com/technology/pub/articles/cioroianu_tagfiles.html

Casper Bang said...

tieTYT: Well that depends on your definition I guess. What I mean is, even if you have schema support, you will still not know what values are allowed in various attributes and it is still painfully easy to nest tags that, may be valid syntactically, but not semantically.

I suppose I have a problem with "let's put a programming language into XML". I have a similar problem with "let's put a query language into annotations".

fsilber said...

Blogger wrote: "Compared to a framework like Struts or Ruby on Rails, Wicket probably decreased my template code by 4x but increased my Java code by 4x."

Ah, but now you have the _opportunity_ to reduce your Java code through the abstraction power of object orientation (e.g. the trivially easy construction of application-specific custom components)! Template syntax, in contrast, is simply not object-oriented and doesn't offer powerful tools for code re-use.

Of course, if you don't really understand how to use inheritance and polymorphism to avoid repeating similar logic all over the place, then keeping the program logic out of the template isn't going to help you so much.

tieTYT said...
This comment has been removed by the author.
tieTYT said...

Wanted to edit the above:

"but now you have the _opportunity_ to reduce your Java code through the abstraction power of object orientation"

But, that opportunity already exists in the other frameworks. I'm not putting business logic in my jsp's, it resides in pojos where I can take advantage of abstraction and OO. IMO, that's where the majority of your app resides, anyway.

Now, on the other hand, if you look at part 4 of my article, you'll see an example of how difficult Wicket made it for me to reuse a 3rd party app. When you talk about these _opportunities_, I think reuse is just as important.

Eelco Hillenius said...

"But, that opportunity already exists in the other frameworks. I'm not putting business logic in my jsp's, it resides in pojos where I can take advantage of abstraction and OO."

Yeah right :-) Well, most apps that I've seen, including ones describes in books use procedural service/ dao layers and flat domain object models. If there's any application where OO shines, it's the UI. A framework like Wicket lets you create - say - a tree with all it's behavior and looks and even resources embedded, that can be extended/ modified by e.g. overriding a method. This is also possible with frameworks like YUI when you go JS/ Ajax all the way. Using Struts and similar frameworks? No way you'll code anything remotely resembling neat OO code.

WRT 4... well some things require a bit more attention to integrate. In return you get reusable components, so when you implement that captcha thingy as a reusable component, you can put it in any page/ panel/ form you like without further adjustements. See for instance http://code.google.com/p/wicketinaction/source/browse/trunk/book-wicket-in-action/src/java/wicket/in/action/chapter09/jcaptcha/JCaptcha.java?r=110

"For those wondering "Why doesn't he just put it in his template and add the Java code?", that won't work: The ReCaptcha script would just generate another input field for you and cause the same problem."

And you blame Wicket for that? That's just ReCaptcha being a pita.

Mario Arias said...

"And you blame Wicket for that? That's just ReCaptcha being a pita"

pretty easy with Stripes

tieTYT said...

"Using Struts and similar frameworks? No way you'll code anything remotely resembling neat OO code."

I agree... if you put all the code in the actions.

"some things require a bit more attention to integrate. In return you get reusable components"

Here's how to add ReCaptcha to a stripes webapp: http://www.stripesframework.org/display/stripes/Adding+a+captcha+(with+reCAPTCHA)

That's pretty reuseable. Just create a ReCaptcha wrapper class and delegate to it whenever you need it.

Eelco Hillenius said...

Yep, that looks fine.

Eelco Hillenius said...

wrt 2:

"You add a Label to your page that attaches to your <title> tag and overwrites the text. Duh!"

Isn't that a logical and generic solution? You put your header section in your page, and if you want that - or anything else on that page - to be dynamic, you attach a component to it. Completely intuitive if you ask me. And if you want to get fancy - say an arbitrary component overriding the page title, that's easy to... just use a header contributor. For both cases are examples in Wicket examples btw.

tieTYT said...

"Isn't that a logical and generic solution?" Generic, yes. Logical, not to me. Maybe to others and I'm just weird. I walked through my thought process on how I expected to do this.

Igor Vaynberg said...

1) there are three books available. the mailing lists are indexed by sites like nabble and markmail which make it trivial to search them. google indexes the lists also.

the wiki is a wiki - it is user-contributed thus the quality varies - i think everyone understands this and takes it for granted.

2) if you have no OO skills, which from reading this post i can clearly see you do not, wicket indeed has a high learning curve because it makes heavy use of OO principles.

you want to override a tag attribute: override the function that generates it Component#onCompoentTag(Tag tag) and use the provided tag object to modify attributes. Or use a provided convenience AttributeModifier to make this easier and shared behavior across component instances.

you want to append something to the head element: override the method that generates it IHeaderContributor#renderHeader(IHeaderResponse response) and use the provided response object to write something into the head. or use the provided convenience HeaderContributors to make this easier and shared behavior across component instances.

you want to make a component's visibility dynamic? override the method that controls it: Component#isVisible() and return true or false based on your needs.

you want to output dynamic value between some tag's you attached a component to? override the method that generates that value: Component#onComponentTagBody(..) and use the provided arguments to write out the body. Or use the convenience Label component that makes this easier.

see the pattern now?

you think php is easier? lets say i have a great include file i wrote that writes out tinymce tags for you. how do i make that include file, which is included inside a form tag write something out into the head element. you cant. i would have to provide two includes: one you have to put inside your head tags and one wherever you want the editor. sucks. so unless you can switch your mindset from top-down rendering to recursive rendering you will not grok wicket.

3) java code is more structured and thus is easier to maintain, refactor, improve, evolve, and change. the compiler for java is a hell of a lot better at catching errors early then a compiler for
markup..oh, wait, there isnt one.

> Wicket doesn't have an official list of, "Cool features that will save you tons of time" anywhere, so you'll likely have the same experience as me.

Wicket's cool feature is that all the dynamic behavior is in java code. but obviously you didnt get that.

4) apparently tons of people who have created components that integrate from yui to gmaps do not share your opinion. you can see them all in wicketstuff.org.

i bet i can create a component that elegantly integrates this javascript captcha into wicket and makes it transparent. just because you couldnt doesnt mean it is impossible. the awesome thing about wicket is that once i do it i can jar it up and anyone else using wicket can reuse it in their project with little or no effort. let me know if you want to put your money where your mouth is :)

5) why would you use wicket to generate javascript or css? wicket generates xml markup, thats it. if you do want to do this we do provide a texttemplate helper that can be used to generate dynamic text tidbits. there is also velocity panel if you prefer to use velocity for this.

6) once again, this goes back to you not having the OO skillset. there is nothing wrong with anonymous classes. the cool thing is that if you find yourself in a situation of writing the same kind of anonymous class over and over you can simply refactor an anonymous class into a top-level class and reuse it. the ide will do all the work for you.

7) i am using wicket on a project now where a designer goes into our source tree and modifies the look and feel of the website. he had to work on jsps before and now swears by wicket. this happened on a project i worked previous to this one in a different company. and the same before that. maybe you are a one-man team so you dont see the benefit.

8) agreed. stateless/bookmarkable stuff IS harder then stateful code in wicket. if you have an app that is totally stateless you should probably not use wicket. however, most apps i worked on, have only a small portion of functionality exposed as public pages, the bulk of the functionality - usually the one with a complex ui - is behind a login page where google cant index it and bookmarkability is not important. you have to choose the right tool for the job.

as a conclusion i would just like to say that: if you have no OO skills wicket will be very hard to learn and use unless you take it as an opportunity to improve your OO skills, which will make you a much more powerful developer.

Peter Thomas said...

I have used Wicket for more than 2 years and even blogged a few comparisons with Spring MVC, JSF, GWT and Seam. I'm genuinely interested in finding the *perfect* web-framework (if such a thing exists) but so far Wicket seems to be it. I keep looking out though - and I promise that if I find something better, I'll switch. Honest!

So I read this article with an open mind, and with great interest actually - because this is the first article critical of Wicket that I remember. Now, that's saying something for a Java web-framework ;)

IMHO the points appear contrived to me and I don't agree at all. Maybe I'll blog a detailed response later.

One question I have is did you have to use Ajax much? As far as I know Ajax support in Stripes is of the "do-it-yourself-with javascript" variety and I haven't seen any Java web-framework that beats how you do Ajax in Wicket.

For me personally, the difference between action-based (Stripes) and component-based (Wicket) frameworks is a big deal and you can find some of my thoughts here:

http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/

I'm also curious as to why you used PHP for your opening example instead of Stripes - your framework of choice. It does look a little FUD-like to me :)

tieTYT said...

You can find examples of how to use AJAX in Stripes here and here. Basically, this is how it works:

1) You use some 3rd party lib to make an asynchronous call to an action
2) That action returns/renders a normal JSP
3) You use your third party lib to place the response somewhere on the page.

Sorry, this is a simplification. I haven't done it for a while.

About PHP... To tell you the truth, I don't know anything about PHP. I just picked a random web framework to show how HTML templating usually works. Apparently everyone interpreted this as me saying, "Use PHP instead of Wicket. It's better, I swear". I was just trying to give a quick introduction to the differences of Wicket and your typical, generic Web Framework.

Igor: It's going to take me a while to reply to your response. I'm working on it. Thanks.

Developer Dude said...

I didn't read the whole article, but I would like to comment on one point nonetheless: the comment about writing less code v. writing less template markup.

All else being equal, I would rather write code than markup, or XML, or whatever else. Most programming languages have IDEs that check your syntax as you type it in, many have type checking for arguments, and most have debuggers.

I understand my language of choice (Java) a lot better than I understand most web frameworks. I am more productive in a programming language than a markup language or web framework.

My choice is GWT. It isn't perfect for everything, but for simple stuff (templated dynamic content) I can use JSP with Spring MVC and GWT for those times where I want a web app, not just dynamic content.

tieTYT said...

Igor: I wrote a detailed response to your comment and posted it here: http://www.assertinteresting.com/2009/03/why-i-prefer-stripes-over-wicket/

Thanks for your reply.

Stephan.Schmidt said...

It doesn't make any sense to compare a component based framework to an action/document based framework.

Choose action, flow or document frameworks based on your needs. They are really differnt things.

Cheers
Stephan
http://twitter.com/codemonkeyism

Freekeswar said...

Great Post - vaannila

seif said...

Well, i don't totally agree with your reasons you don't use wicket. I think wicket is one of the most great java web framework in the concept. After a lot of search, IMO there not a lot of frameworks that make a real separation between java and html .. i only found wicket and tapestry ... and the tapestry 5.1 doesn't generate valid xhtml content. In comparaison with tapestry, wicket have a lot of doc.

The only problem i found with it is to use it with DI. Wicket does not have support for @EJB annotation. I know there is the wicket-contrib-javaee in the wicketstuff repository but i seems that there is a hug bug with it or with the wicket-ioc jar: when you use ajaxified forms, it works really great ... but try to use the back button in your browser and submit again any data ... you'll see a very beautiful java exception that told about a problem with deserialization :(

That make this framework really unusable in production :s

Eelco Hillenius said...

Then build in support for those EJB annotations. I never needed it (using Spring or Guice with my Wicket apps), so I've never looked at it, but it can't be more than a few classes to implement it. Including making sure serialization exceptions don't happen, which when gone should allow you to have regular back-button behavior.

seif said...

well ... as you suggested, i have converted my ejb object with a spring one.
i got exactly the same exception using a form with an ajaxbutton when i submit after click on th back button of my navigator:
Unexpected RuntimeException
java.io.InvalidClassException: net.lebonchoix.service.IAppDao; could not resolve class [net.lebonchoix.service.IAppDao] when deserializing proxy
at org.apache.wicket.proxy.LazyInitProxyFactory$ProxyReplacement.readResolve(LazyInitProxyFactory.java:236)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:597)
etc ...

Eelco Hillenius said...

Hard to determine why that is without knowing more about your source code and setup. Looks to me like it is a classpath problem, maybe a container issue. Also, the fact that Wicket is trying to serialize a DAO is smelly... you should probably use a proxy there (like @SpringBean) or have another way to avoid keeping a reference to the DAO so that it isn't serialized in the first place. Try to mailing list with a good explanation (and maybe quickstart project) if you want more help.

rosy said...

i like ur website. thanks for this comment posting...
web development

安室 said...

很好啊..................................................

Andrey Rybin said...

2 florin:

Thank You very much.
I tried Click. I should say: Click is really cool!

黃金獵犬 said...

快樂與人生,是最好的伴侶........................................

健康保寶 said...

辛苦了!祝你愈來愈好!........................................

ispomyju said...

Many thanks have your share..................................................

lady said...

快樂的微笑是保持生命康健的唯一藥石,它的價值千萬,卻不要花費一文錢........................................

惠蘋 said...

線上免費成人網gogo成人影片a成人短片尼克成人電影免費觀看成人動畫包銷小老鼠卡通 h 網卡通 h 影卡通上床做愛影片卡通女影片卡通片成人卡通成人片免費看卡通成人免費卡通成人網站卡通色動畫卡通色情無碼卡通色情短片古裝成人片線上看日本無碼影片觀賞手淫過度日本AV免費?影日本av影片線上看日本a片商日本a免下載日本a免費下載日本a免費片日本a短片日本a試看日本a影片線上免費日本a線上看色咪咪影片網一夜情聊天室嘟嘟成人網視訊交友

國男皓云 said...

how do u do?................................................................

倫音 said...

Virtue dwells not in the tongue but in the heart.......................................................

v奎峰奎峰 said...

Hello~Nice to meet you~..................................................

友辰 said...

Cool blog網愛聊天室色情網站交友找啦咧免費影片成人笑話成人圖庫sexy女同志聊天室愛戀情人用品情趣爽翻天咆哮小老鼠入口85cc6k脫衣人妻sexy85c脫光光taiwansex淫女情色成人男女做愛美女做愛脫衣秀a片正妹淫蕩色情後宮040185c85c77p2p77p2p性幻想手淫18禁

勝傑懿綺 said...

你怎麼能經過一片海,而忘記它的藍?......................................................

長卉LisetteC said...

nice job! waiting for your new artical. ........................................

ac21f2d2 said...

Such attentively manages your ~
.....................................................

DamionHallam3216 said...

Haste makes waste. ....................................................

文迪 said...

may the blessing be always with you!! ...............................

韋于倫成 said...

良言一句三冬暖,惡語傷人六月寒。.........................

MickiRueda said...

85cc免費影城 21sex美女視訊交友 日本avdvd女優xxx383美女寫真 sex520-嘟嘟成人 後宮視訊 閃亮天使520視訊聊天室 a片線上試看85cc 小園春夢現代文學小說 辣妹視訊免費體驗 情人輔助品成人網站做愛自拍偷拍 免費線上觀賞卡通影片 69性殿 4u成人-sex s383視訊玩美女人 免費視訊聊天1768 0204 視訊交友 微風成人論壇 hi 5 tv 影音聊天室 ut視訊聊天室 蔡依林性感影片 38girl視訊交友 dudu sex免費 aa 片試看 tvnet0204 我愛你視訊美女拳 比基尼av辣妹影片 383movie成人影城 免費影音下載hibb 免費視訊辣妹av1688 網心之悸動聊天室 無碼女優,免費色情電影 av969 免費短片 視訊妹迷愛聊天 免費色咪咪視訊網pc交友 avshow成人情色網 一本道 a片 東京熱免費試看短片a aa片免費看 免費視訊聊天 辣妹性愛文學 日本視訊 免費視訊辣妹性愛巴士 南部聊天室情人視訊網 成人影片下載383movie影城 美眉1768 meet520 com 視訊聊天997 sex888movie影城免費a片 伊莉論壇 兼職援交米克綜合論壇 聊天室找一夜 情色性愛貼圖,人妻 視訊聊天室angeltong 百事台南視訊

易英易英 said...

人生中最重要的是要自尊、自愛、自立、自強、自信。 ....................................................

曾文詠 said...

Birth is much but breeding is more. 加油!..................................................

rlkris said...

一夜聊天室uthome聊天ut網際空間聊天ut 網際空間聊天高聊天室小澤瑪莉亞免費影片線上收看小澤瑪莉亞短片線上看小澤影片小護士試看小魔女天堂免費影片小魔女天堂影片交流小魔貼片區小魔與天天色情直播天天色情影片下載天天直播影片天天聊天天天聊天室天心寫真集dvd天心寫真集影片天堂圖貼夫妻如何做愛夫妻性愛方式夫妻性愛影片夫妻房事播放影片夫妻影片天天色情下載天天下載色情影片天下天圖網小魔蠍小弟弟影片交流區 小弟弟影片區 自拍貼圖視訊交友

威隆 said...

Many a little makes a mickle...................................................................

孝仁家明 said...

這個時代,不缺乏感傷,但缺乏反思~~希望能多看到值得思考.................................................................

淑君 said...

Pen and ink is wits plough. ....................................................................

亦妮 said...

河水永遠是相同的,可是每一剎那又都是新的。....................................................................

宛真宛真 said...

幸福不是一切,人還有責任。............................................................

毓er曹妃sf炳hd張jtr珠 said...

It takes all kinds to make a world.............................................................

雲亨雲亨雲亨 said...

當一個人內心能容納兩樣相互衝突的東西,這個人便開始變得有價值了。............................................................

茂慧茂慧 said...

還是喜歡這裡-支持你..................................................................

佩璇佩璇 said...

Say not all that you know, believe not all that you hear.............................................................

維哲維哲 said...

文章是心情的反應~~祝妳天天寫的都是讓人開心的好文章哦!!............................................................

倫惟倫惟 said...

我真心在追求我的夢想時,每一天都是繽紛的。因為我知道每一個小時都是實現理想 的一部份。..................................................

蔡靜芳蔡靜芳 said...

正點喔 多謝大大無私的分享 感恩拉( ̄∀ ̄)......................................................

原秋原秋 said...

生命的意義,是在於活的充實;而不是在於活得長久。............................................................

雅莊王edgd春2蕙婷余惠其 said...

人生有如洶湧的波濤,如果沒有岩石的阻擋,怎能激起美麗的浪花?............................................................

琬安琬安 said...

Necessity is the mother of invention..................................................................

曾戴山柔曾戴山柔 said...

一時的錯誤不算什麼,錯而不改才是一生中永遠且最大的錯誤..................................................

張志亦劉美玲 said...

快下班囉~來幫你加油~~.................................................................

凱v胡倫 said...

所有的資產,在不被諒解時,都成了負債.................................................................

家唐銘 said...

一棵樹除非在春天開了花,否則難望在秋天結果。............................................................

沈貞李添睿儀 said...

快樂,是享受工作過程的結果......................................................................

靜詹怡詹詹 said...

感謝你的分享 要繼續發表好文章喔..................................................

于庭吳 said...

知識可以傳授,智慧卻不行。每個人必須成為他自己。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

怡靜怡靜怡靜怡雯 said...

跟您打聲招呼,願我們大家都更好!!..................................................................

佳張張張張燕張張張張張 said...

生命如夏花洵爛;死如秋葉之靜美。........................................ ........................

江趙雲虹趙雲虹仁昆 said...

心平氣和~祝你也快樂~~..................................................

王怡迪 said...

真是感人肺腑的文章~~......................................................