Why Wicket looks cool
I like the looks of Wicket for a couple of reasons - without even using the framework yet.
- Its project homepage looks good. If you're using a Java web framework, chances are you're developing UIs too. If you don't know how to make sites look good - it's time to find a new line of work IMO. Of course, learning how to make good-looking UIs is another option.
- Its Wicket Stuff project. It provides Hibernate, fValidate and Spring integration. It also appears to provide an option to use Velocity for your templates. I'm not sure what the Velocity integration provides - since HTML templates (ala Tapestry) should do everything that's needed.
What I don't like about the project:
- The Buzz page has a quote that's (apparently) from this site. Unfortunately, it looks like I said it - which I didn't.
- There's no books being written about it. If it's really that good - where's the books? Ruby on Rails will have 3 by the end of this year. Any good framework should inspire books to be written about it.
- The Wicket Stuff project has no documentation. Javadocs don't cut it. Tutorials are king.
I hope this project succeeds - Tapestry needs some competition and I don't think JSF is providing it. If JSF adds HTML Templates (or I figure out how to use Java Studio Creator to manage an AppFuse+JSF project), that's a different story.
Posted by Matthias Wessendorf on April 14, 2005 at 03:13 PM MDT #
I should mention that even though I hate the tagsoup, learning JSF after using Struts/Spring/WebWork was much easier because I could re-use my JSP knowledge. With Tapestry that wasn't possible. Another thing I find amusing about JSF is that Managed Beans are almost *exactly* the same as WebWork Actions. When I integrated JSF into AppFuse - I was able to copy my WebWork actions and only change a few things.
Posted by Matt Raible on April 14, 2005 at 03:17 PM MDT #
- Sorry about the buzz thing; we should have asked you first. We'll remove it this weekend.
- We are looking for people that want to write a book about Wicket.. interested ;)?
- There is work in progress on the tutorial on our Wiki. We agree it is by far not sufficient, and we *do* plan to have at least a decent tutorial soon.
The Velocity panel can be used for CMS like applications where part of the content is pulled from the database, and you want to provide the content maintainers with basic scripting and some context objects. I'll use it for a pop venue CMS project (that is used by four dutch pop venues btw)Posted by Eelco on April 14, 2005 at 03:19 PM MDT #
Posted by Jeff Sheets on April 14, 2005 at 03:19 PM MDT #
Posted by Martijn Dashorst on April 14, 2005 at 03:28 PM MDT #
Posted by Curt Hibbs on April 14, 2005 at 03:58 PM MDT #
My bad. That quote was my work and nobody else's and I have removed it. When I said "post" I meant "comment". I wasn't trying to imply you said that, Matt... I just wasn't thinking too carefully about how people would read it.
As far as books go, I think often a project's originator writes the book about it. But I'm definitely /not/ going to write a book about Wicket. The reason for that is not that I think Wicket is unworthy of a book. On the contrary, I think it's one of the more interesting new technologies out there (if I do say so myself). The reasons that I don't want to write a Wicket book are that I have no time to do it now, I generally do not enjoy the process, the User's Guide I started 9 months ago has little to do with Wicket today and ultimately the economics of writing a book do not make any sense (to me). I'm definitely hoping someone else will write a book about Wicket and I would certainly support such an effort as much as I can. For myself, I'm hoping to find some work in the next few months doing Wicket consulting somewhere. Ideally, I might like to work overseas on Wicket project. ;-)
Regards,
Jonathan
Posted by Jonathan Locke on April 14, 2005 at 06:28 PM MDT #
And also the state in session stuff.I try out wicket demo and find that it's really irritating to stale page.say, sign in page. when I'm signing, and click back button, and it won't let me sign in again, it always say the page's stale.(and also the list page) , try click edit/remove and click back button.I guess it's too irritating and unfriendly to behave like that.
Third, compared to the templating stuff, it's more rigid to use listener method in Java , templating stuff can make more dynamic page than this. for example, in webwork, you can put some template in database and render it, constructing a highly dynamic page( very useful in portal/portlet developing), and since its form action url is just string, you can put it in template.but if you use Listener stuff, you can't construct that b/c you have nowhere to dynamic construct some listener method.
Yes, I admit the component approach is really appealing, but I guess it has some drawbacks when comparing to classic way . so I'm sticking with webwork now ,which is really really a great web framework.
femto
http://femto.blogdriver.com
Posted by femto on April 15, 2005 at 04:24 AM MDT #
Posted by Jonathan Locke on April 15, 2005 at 06:07 AM MDT #
I guess you mean by the 'form rewind' what we call the 'undo' recording. This undo feature IMO is good as it is relatively cheap (compared to serializing your whole component tree), and it is quite configurable; as a user you can decide whether it happens at all, and if the recording is supposed to happen, you can customize the way that it is done.
Agreed that if you use large list, recording is not allways what you want. You can turn it off (and stop supporting the back button), or you can externalize the state of your component by having everything you need in your URL. The latter is what you are used to by using web mvc frameworks. You can do that now in Wicket with some work, but it is on our todo list for 1.1 to make this easier.
I wonder what part of the demo you are talking about. With Wicket, pages are only marked 'stale' when the were explicitly set to that state. Since we use the 'undo' recording as the default, you should normally be able to use the back button transparently.
It is very easy to get around what you call the rigid structure. We even provide an out-of-the-box component for it (Velocity Panel), but if you look at that code, you'll see how easy it is. In case you want to make your custom templates actually *listen* to e.g. form changes, you could quite easily use bookmarkable pages (which take in any number of request parameters) for that.
Sure, there's pro's and con's to everything. I know, some things *at first sight* are easier using a web mvc framework. However, I know now from experience that that approach is just not suited for developing complex user interfaces with large teams. I want a framework that enables me to write good OO code and not have me ending up in a nightmare of chaining commands/ using interceptors to do stuff the framewok should have done for me in the first place. Also, not being able to reuse components has been a major disadvantage for some of our projects. That is just something you need on large projects, especially when you have several projects which share commons business funcionality. Finally, we give transparent clustering support special attention, which is something that will allways be difficult to manage (especially in large teams) with (web mvc) frameworks that don't shield you from the gory details of state management.
Posted by Eelco on April 15, 2005 at 06:35 AM MDT #
Posted by femto on April 15, 2005 at 08:42 AM MDT #
Posted by Eelco on April 15, 2005 at 09:35 AM MDT #