> > 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. i am familiar with spring so that is what i chose to build > the example of how not to do that, same functionality can be accomplished > with a slew of other technologies. > > so far all i see is whining that we should have a wicket/hibernate > integration framework, but no one has actually pointed out what > features/functionality it should provide. so how about something more > concrete? and an explanation of why wicket - a user interface framework - > should provide transaction management services.
I wasn't looking for a binding between wicket and a persistence layer. However, given that ever increasing numbers of projects are using ORM frameworks, which are all too likely to allow lazy initialization of relationships, it would be nice to have a best practices solution to the problem of closing an open session or transaction that is necessary in order to allow lazy instantiation. In reality, such a solution is unlikely to involve binding anything other than a config file to Spring/Hibernate, something like a servlet-plugin in web.xml, for instance. My point isn't that this is necessarily a difficult problem to solve, but that it would be nice to establish best practices methodology, especially for those who are investigating a new technology and want to get a sense of how it will work with their other tools without having to spend 2 weeks learning a framework. The same goes for the problem of detaching and reattaching to model objects which are dynamically loaded at request time, rather than being stuffed, in their entirety, into a session. This is particularly important when clustering servlet containers and serializing sessions between servers. Such code doesn't need to be bound directly to the ORM framework, but there does need to be some mechanism for business objects to be replaced by some kind of id and then be able to re-instantiate those objects prior to servicing subsequent requests. Wicket apparently has such a mechanism, so why not provide a suggestion about how to use it? And yes, the phonebook example does exactly that with the DetachableContactModel object, but it took me nearly 2 weeks to discover it. Let's face it, if Wicket is going to be taken seriously as as an interface framework for J2EE apps, it is going to have to integrate well with Spring and Hibernate, allowing a developer to extract maximum benefit from those frameworks. Of course, odds are very good that it already does, but that is entirely NOT evident to a new user. Establishing a best practices document not only gives new users a starting point when starting a new project, but it assures them that the integration they desire is readily available. Meanwhile, I'm probably heading off to Tapestry. As much as I like wicket, without viable documentation, I can't risk using it at this stage in its development. I can't bear the thought of a struts-style MVC framework, so Tapestry appears to be the only well documented, mature, J2EE interface framework with a community of developers large enough for me to want to risk using it, even if it is possibly my least favourite component based framework. And folks, please don't neglect the value of solid documentation. Wicket has a ton of potential, but I've seen some very promising open source projects fall by the wayside almost entirely because they weren't accessible enough to users that decisionmakers were willing to gamble on their use. I'll be keeping an eye on wicket's progress, and look forward to the day when I can migrate to the framework. --sam ------------------------------------------------------- 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
