One thing I mean by integration is a built-in loadable detachable model
for Hibernate mapped objects, like what's in contrib.data and
contrib.database. After that, you need an easy way for people to fill up
list views with query results. If there weren't a use for base classes
that help in these tasks, the several contributed ones would not exist.
This isn't really a "tier" argument (thank God), it's about giving
people a starting point and suggested structure for accessing a database
in a Wicket application. Pretty basic stuff if you ask me, and I do not
think that a pile of contributed packages and examples is much of a
solution.
Nathan
Nick Heudecker wrote:
I have to agree with Igor here. I didn't have to do anything special
when I started using Wicket. The DAOs and Service tier that I had in
place worked fine.
It could be argued that if you're integrating Hibernate at the Wicket
level, something is wrong in your design. However, I understand that
for simple apps, multiple tiers is overkill. Things like Spring's
OpenSessionInViewFilter still work, or you can roll your own filter and
have it set the session in the WebSession.
Perhaps I'm confused on what you mean by integration.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
