I still haven't had much time to look at Wicket, which just announced a 1.0 release. I did see that their examples include a Hangman application (the new industry standard, I guess).
I think many of their goals are quite laudable; less XML is a good thing (you may notice I'm on an annotation streak right now).
I do have some questions about lifecycle; I need to dig into the docs or code to see how they maintain page state across requests; I'm concerned that each session will get a giant serialized tree of components, something that Tapestry's structure works exceptionally hard to avoid ... even though seperating a page's persistent state from the tree is what lead down the abstract accessor method path in the first place.
I was amused by the live examples; the URLs that were generated look like Tapestry 0.0.1 URLs (I could even see the loop index terms in the middle of the URLs). Tapestry has taken some flack for ugly URLs, which are much improved in Tapestry 4.0 (in fact, limited by the Servlet API more than anything else).
Wicket seems to have a page-state version number encoded into the URL to detect browser back button issues (Tapestry, of late, has been moving towards storing more data in the client to circumvent problems caused by mismatched client- and server-side state).
Mostly, I'm envious of the chance to start with a clean slate. The demand for backwards compatibility is surely holding me back from fixing a good number of things. And if I was starting again today, I would not require subclassing from base classes (as Tapestry and Wicket both require). It really would be POJOs, plug optional interfaces and naming conventions (and maybe annotations) ... and no XML at all.
At the end of the day, it's great to see folks "gunning" for Tapestry, it's a kind of validation. I'm looking forward to meeting the Wicket crew at JavaOne.
Further discussion on The ServerSide.
6 comments:
Maybe after Tapestry 4.0 is rolled out, you can start new webframework (Gobelin ?) from clean slate ?
I think a few more transition releases, and maybe introduce some cleanups that are not backwards compatible.
If I start fresh, it won't be in Java. There's no point in splitting the community. 3.0 -> 4.0 has been damaging enough.
>>>If I start fresh, it won't be in Java.
Wow ! Tapestry.NET ? or Rug on Ruby ? :))
.Net never even crossed my mind (though if someone has deep enough pockets, I could be convinced). Nope; I was thinking Ruby ... but so far, all I have is the name: Rapture.
Say what, maybe by the time you're thinking about Tapestry 5, and we're thinking about Wicket 2, we should see whether we could combine efforts :)
We (Wicket) are primarily targetting the current model 2 crowd and that part of the JSF target audience that want maintainable projects instead of short-term VB monkey successes.
In response to the 'Clarity' effort you might want to think a bit more about combining efforts.
Post a Comment