Wicket - IDE Support

Last week I restarted checking out the Wicket framework. I specifically looked for IDE support. I started off by checking out
-  Eclipse support: And I found WicketBench. I set it up and initially hit upon some problems. Wicket Bench is supposed to use jetty as the web container automatically but somehow it does not come with a internal jetty jar when installed. This seemed strange to me but I never the less went ahead and provided a jetty jar (took the latest) of my own. Again ran into problems. I figured out later that WicketBench works with Jetty 5.x version and later versions are not supported. Again something which I felt was not right. After sorting that out, I was able to start with doing some development. I used there unit testing model and was initially impressed with the ability to run pages independently. This is still a good feature. But then again when I wanted to run the entire application in one go, I could not find any simple way of doing it. I did not want to write selenium tests to just do some wicket research, hence don't know whether that can solve the problem. Even if it does, I still feel there is merit in providing a simple way to launch the entire app in one go and somehow I could not find any. That sort of sealed the deal with my wicketbench expedition. I decided that it is not good enough
- Netbeans support: The next obvious IDE to look at was Netbeans (I don't yet intend to pay any money for the IDE). Netbeans seemed to have a decent support for Wicket. It does not provide the capability to test single pages (like WicketBench) but testing out the application using tomcat is pretty simple. It provides you linking between html based wicket ids and java components in the java page. Also there seems to some effort to improve support on html palette for wicket components. These sound promising. I found myself pretty much happy for now.
As of today at least, I feel the support for Wicket is far better in Netbeans than in Eclipse.    

JSF pitfalls article I read

I found a good article on JSF Anti-Patterns & Pitfalls on theserverside. This covers a good set of JSF pitfalls. I am summarizing them here
1. absence of constructor based dependency injection - The developer has to sacrifice some of the OO flexibility - Use spring instead
2. no provision to pass parameters to the managed bean methods - Developer use various hacks like implementing Map
3. dual call to phaselisteners - this is something which i did not realize - looks more like a bug to me :)
4. huge amount of navigation related xml - this is something we faced - Usage of * can help. This is some trick I probably missed in my project
5. using xml causing runtime exception - this is quite true; may be tools could help - author recommends annotation libraries from Shale and Seam
6. thread safety - some important info in this especially about custom converters and validators. something that should be kept in mind
7. creating component renderer tags with behavior - something to be avoided
8. exposing the entire object hierarchy in el - not sure about this one; done this quite a lot. seems more natural
9. coding to the implementation instead of interface - this is something which we must not do at all
10. not doing view state encryption on client side - good point in terms of security
11. jsf code that is bound to the servlet api - something which i have done a lot I think - this makes it non compatible to portlets - workaround mentioned

That is what is covered. The other issues I faced are already covered in a previous post. Folks who use JSF please keep these in mind

JSF - My experiences

For the last two-three months I have been working on JSF (My Faces) with facelets. The experience has been good for most parts. The components available out of the box with JSF implementations (standard, tomahawk, richfaces etc.) have been of great help with development. The decision of using facelets was a good one. It helped to make the view much easier to format for user experience. With all these good things, I found some really seemingly trivial but irritating issues.
- Handling blanks with input fields that are bound to non-string values is a problem (though luckily solutions are available - specific converters).
- There were scenarios where I switched from tomahawk components to standard components for making things work. The reason for which I never could understand.
- A navigation rule syntax which is really very verbose.
- A backing bean which can get quiet large and unwieldy depending on the features to be handled.
- Making pop-up screens for lookups etc. - I could never get it working.
Some of these can get irksome, but I still felt that with Facelets, JSF makes web development far more easier.
I would like the JSF gurus to throw light on how these problems can be handled and also add on to the list of the advantages and issues of JSF. It would be of great help to me and many others