• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Wicket in Action - Learning curve for Wicket?

 
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Martijn and Eelco,

what do you think how high is the learning curve for Wicket in contrast to other existing frameworks? A first look at it gives the impression it may be a lot easier to learn than for example Spring, JSF, Seam and all the others. Do you think this is true?

Is it furthermore possible to integrate existing knowledge and technologies like the Java persistence API for example? Or is it bound to Wicket specific technologies?

Marco
[ May 20, 2008: Message edited by: Marco Ehrentreich ]
 
author
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Marco Ehrentreich:
what do you think how high is the learning curve for Wicket in contrast to other existing frameworks? A first look at it gives the impression it may be a lot easier to learn than for example Spring, JSF, Seam and all the others. Do you think this is true?



It depends on your background. Most folks coming from a Swing background (or Borland Delphi background for that matter) have little to no problem adjusting to Wicket's programming model. Using components and events such as a Link's on Click is natural to them. It also seems that using Wicket's models (the glue between your components and your business objects) is more natural to the Swing programmers.

We have had a big number of folks coming to Wicket from Struts/Spring MVC/et al. and they seem to have initial problems with the abstraction. You can compare it to being a JDBC/SQL programmer being familiar with ResultSets and PreparedStatements and suddenly having to work with objects and collections when switching to an ORM such as JPA and Hibernate.

Seam is not only a different framework, but addresses a different problem. The Seam guys are building some integration with Wicket. But I don't use Seam (yet) and don't know the status, or how well it integrates.

Is it furthermore possible to integrate existing knowledge and technologies like the Java persistence API for example? Or is it bound to Wicket specific technologies?



Wicket is a web UI framework. We think it is important to focus on that mission, instead of trying to do everything. This means that we will integrate with anything. iBatis, Hibernate, Cayenne, JPA, db4o, spring, guice, jquery, scriptaculous, yui, jfreechart, jasperreports, ... It is very easy to integrate with these technologies (for Spring and Guice we have core projects that provide the integration, chapter 13 of Wicket in Action introduces Spring and Hibernate integration).

[ May 20, 2008: Message edited by: Martijn Dashorst ]
[ May 20, 2008: Message edited by: Martijn Dashorst ]
 
Marco Ehrentreich
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your detailed answer Martijn!

So do you think it's possible to build some fair web applications after just reading your book given average experiences in Java web technology, component oriented development, frameworks and so on?

You know, about 400 Pages isn't too much and a lot of other frameworks are so complex that you soon realize you should have read dozens of other books to be able to actually use the framework or technology. I think this is really frustrating and of course some technologies just are so complex that it's really no possible to get all information from one book or tutorial. Wicket seems to be a lot easier as a first look on the homepage and examples suggest.

Can you confirm this first impression regarding your personal experience with it?

Marco
 
Martijn Dashorst
author
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


You know, about 400 Pages isn't too much and a lot of other frameworks are so complex that you soon realize you should have read dozens of other books to be able to actually use the framework or technology.



Well, writing 600 or 800 pages is not that hard, the hard part is to make decisions on what to include and what not. You are bound to disappoint people, because 400 pages can only contain so much information. But we wanted to write a book that is not overwhelming and doesn't need a shelf of itself - 350 pages seemed like a good idea at the time, and I still think 350 pages should be enough, though we barely got under 400.

I think this is really frustrating and of course some technologies just are so complex that it's really no possible to get all information from one book or tutorial.



We tried to give the reader of the book a solid foundation. A lot of folks on the Wicket lists tell us that they have improved their Java knowledge by building Wicket applications. I even learned a couple of new trick I didn't know. For example:



This is something I rarely use, but I learned it through some Wicket programming. It is a nice alternative to the usual anonymous inner classes we typically use to extend a component.

Can you confirm this first impression regarding your personal experience with it?



Well, as a committer on the framework and author of the book, I might be not the right person to ask since I've long passed the stages of beginning with the framework. Going back through memory lane, it took a while to grok the "lazy evaluation" and the model concept.

That said, at our company we have a lot of programmers coming in from college/university and they seem to be up to speed with Wicket in a matter of days.
 
Ranch Hand
Posts: 471
Mac OS X Hibernate Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Marco Ehrentreich:
a lot of other frameworks are so complex that you soon realize you should have read dozens of other books to be able to actually use the framework or technology.



Well, I have a comment here. Books do not give you every single detail you might need for a framework. They give you the most important stuff to get you started, and as a reference for most common problems you might fall into. I agree that some frameworks (like spring for instance) are huge, and a dozen of books on the subject is not enough to know every single thing about it, but I have to say that you don't necessarily need to know every single thing about a framework. You would normally need just what would get you started, then you can discover everything else from the API documentation (assuming that they are well documented).
 
Marco Ehrentreich
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Alaa,

perhaps it was a little bit exaggerated that you always have to read so many books from the beginning to the end. Of course, as you said, it's usually not necessary to know all the details of every incorporated technology from the start.
But a lot of frameworks are built on top of other frameworks or components and so you often have to understand at least the basics of most of these components before you can effectively use a framework. If you're already familiar with some of these concepts and technologies this may not be a big deal. But for beginners who have to learn everything from scratch it's surely a drawback of such frameworks.

Marco
 
reply
    Bookmark Topic Watch Topic
  • New Topic