I don't agree with wicket-contrib-data being obsolete. What happened is that I created some basic Hibernate support classes last year, and that other people commented that they didn't like them so much, and wanted to add alternatives. From there it grew into the bunch a quasi related classes it is now. I still think classes like HibernateObjectModel are pretty useable. You may argue about how elegant the choices as hibernate session delegate etc are, and you may even argue that it is not best practice to bind to Hibernate in your view layer. But not every project has to display the perfect seperation of (service) layers and these classes gives users the opportunity to go for a more RAD approach. Depending on how much Phil (and did other people work on that project?) wants to keep, we could do a clean-up and keep only the classes we still think are usuable.
We don't have to promote the project as best practices, but saying it's obsolete goes a bit too far. Eelco On 11/20/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > wicket-contrib-data and wicket-contrib-data-hibernate do not provide any > form of transaction management. furthermore, they are obsolete due to > repeater package (what used to be wicket-contrib-dataview) in > wicket-extensions. > > also, this discussion did not have much to do with spring itself, but with > the fact that it isnt the greatest idea to tightly couple your persistence > layer with your ui layer, because that forces your business logic to live > inside the ui. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
