> I didn't say my cons were valid - but I do believe there *are* cons to > Wicket. What are they - in your opinion?
You know what I think the pros are by now. I don't always feel the same about the cons we currently have, but currently they would be: * Ajax support is a compromise. We can't really help this, and I feel we did/ are doing the best we can, but our Ajax support suffers from the fact that we're trying to support both a traditional (page based) and ajax approach. Particularly, back button support, bookmarkability and asynchronous server handling suffers. Some of this might still be improved in future versions, but I think we're already easily one of the most complex web frameworks out there when it comes to the internals, and these fixes are only gonna make things more difficult. * No Hybrid approach to state handling. I know many team members disagree here, but I've always had in my mind that the perfect approach to state handling would be to give users the choice between server managed and client managed (i.e. by passing parameters/ rest) on a component level. To our defense, none of our competitors support this either, at least not on the component level I am envisioning. * Java. I'm getting tired of Java's limitations and plain inelegance in some areas and how this sometimes makes Wicket verbose and even inflexible. I'm starting to get very interested in languages like Haskell, Erlang and Scala. Maybe it's just a phase I'm going through, and I'm sure that people who hate anonymous classes would hate FP even more ;-) Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
