Geert, Excellent, thorough answer, thanks.
You can using Spring together with RIFE, and Hibernate also. We actually advocate using Spring as an IoC reference factory since we didn't bother writing our own, we only focused on the injection part. You will however miss out on some of the nice integrations of our persistence layer when you use Hibernate. However, nothing prevents you from using Hibernate for certain things and use our ContentQueryManager when you want easy integration with our content management framework, for instance (http://rifers.org/wiki/display/ RIFE/Content+management+framework).
I have actually grown to loathe Hibernate, and would be keen to avoid using it again - most of the debugging time on the last couple of systems was on obscure Hibernate issues, for which the Hibernate forums were pretty well useless, as all answers from the Hibernate guys tended to be extremely terse 'RTFM' style ones. (Maybe if their error messages were not so obscure and/or misleading, people wouldn't keep asking about them?). Spring makes life with Hibernate a lot more pleasant, and one feature of that would be something I would really miss if it were not possible in RIFE. Namely, the declarative transaction management - e.g., you tell Spring (via the XML config file) to wrap all methods beginning with 'insert' or 'update' in your Products DAO bean in a transaction, and that's all you have to do. What does RIFE do in this area?
While I only briefly glanced at SpringMVC, I wouldn't recommend it. It seem too difficult and not very intuitive.
Seems nice by comparison with Struts!
Comparing RIFE with Wicket is difficult since you're comparing totally different approaches. What I don't like about Wicket is that you're forced to think of everything as being a component, while many web functionalities really are simple request/response actions. RIFE combines both of these and make any action handler a reusable component (http://rifers.org/about).
I see your point.
The thing I like most about Wicket is also the biggest flaw imho: you do everything in Java in a similar fashion as Swing. During the coding this is certainly very nice and you can write everything here and now. However, when looking at code that someone else wrote, you have to read all the sources to get an idea of how everything relates. There's no single overview that summarizes the logic flow and data flow for you. It's thus very difficult to gets a complete view of how your web application interacts with the outside world (ie. the RESTful API of your application). Note that RIFE doesn't force you to use XML for your declarations, you can do them in Java too if you want (or Groovy or Janino: http://rifers.org/wiki/display/ RIFE/Site+structure+and+element+declaration+without+XML).
While I haven't joined in with the mad stampede away from XML which seems to have been triggered by Ruby On Rails, I would say that having to read Java sources to work out how things relate doesn't particularly bother me. In common with many Java developers, I suspect, I find well-written code rather easier to read than XML. Even the leaps from one class to another are not really a problem if you have a good IDE (which I do, being the 'other user' of that extraordinarily well-kept secret, X-develop, which I know you favour - that makes two of us now :-) ). Having said that, I think it's great that you can use XML, Groovy or Java for RIFE.
I also suggest that you read over a mail that I wrote when someone asked about a WebWork/RIFE comparison, it contains a number of points that I didn't repeat in this mail: http://www.uwyn.com/pipermail/rife- users/2004-September/000643.html
I read this, thanks. It was also very useful. John -- ============================================== John Moore - Norwich, UK - [EMAIL PROTECTED] ============================================== _______________________________________________ Rife-users mailing list [email protected] http://www.uwyn.com/mailman/listinfo/rife-users
