Angelo, It's a solid base surrounded by shifting sands.
The situation now with T5 is a bit like that with T4 a year an a half ago. If you don't mind a long-winded explanation, I'll describe my past experience. My choice should make more sense. I was (and really still am) new to the "web thing" as well. Tapestry for me was a technology waiting for a project: I selected it three years ago as the best approach to designing web applications but wasn't doing any web development at the time. I was given the green-light on a project in early 2006 for a web application to service a call center and one of its clients until the client's CRM initiative could be completed (still waiting by the way). The application used: T4.0 Hivemind 1.0 Hibernate 3 Hibernate Annotations Spring 1.2 Acegi Security T4.0 was changing. Hibernate 3 was still immature. Hibernate Annotations were beta and changing (partly to match changes to the EJB3 persistence spec) and did not include all functionality. I had never used any of the technologies before. I was climbing multiple learning curves on beta frameworks with changing API's. Documentation was frequently limited or out of date. I bumped my head on form data that failed validation being persisted anyway with errors because of default Hibernate behavior, or changes that were or were not persisted based on Cascade settings. I had problems that most people don't seem to hit because of the inheritance hierarchy in my application. I hit errors that would leave transactions open and give me deadlocks. I had problems accessing datasources, and errors generated by crappy Microsoft JDBC drivers. It was a nightmare / death march / "whatever doesn't kill you makes you stronger" time. Tapernate arrived during my development as did Honeycomb. Both looked very interesting, but I had already solved my biggest problems using Spring. Neither was documented enough for my needs. My application accesses multiple backend databases. That's actually pretty normal for me, but isn't well handled by the easy drop-in configurations you see. I also use Hibernate interceptors extensively for detailed logging. My security (Acegi) extends down to the entity level. With so many hills to climb, I couldn't afford to figure out how to do what I wanted using Hivemind. I had samples to follow with Spring / Hibernate. The same now goes for T5's IOC container. My Spring application.xml files are not DRY (Don't Repeat Yourself). They're quite WET (Wasteful and Excessive Text). But they work. I understand them. I know why things happen. I have another moderate size project coming up early next year where I will need to make similar decisions. Maybe the answers will be different, but right now if I want to have confidence in my transaction management I use Spring. I hope that helps. Jonathan > -----Original Message----- > From: Angelo Chen [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 21, 2007 9:11 AM > To: users@tapestry.apache.org > Subject: RE: T5: Tapestry-Hibernate, do we have to save()? > > > Hi Jonathan, > > I'm new to this web thing, I'm using now Tapestry with Hibernate and found > them so convenient together, I'd like to know what is the advantage of > using > Spring with Tapestry, particularly T5 considering T5 has its own Ioc as > well. Thanks, > > Tapestry-Hibernate is working very well, of course my app does not yet > require those strict transaction management, I do like to see it will have > this transaction/concurrency facilities built in, but still too new to > understand the inner workings. > > A.C. > > > Jonathan Barker wrote: > > > > > > My more complicated work has been with T4, but this should still apply. > > > > I use Spring and Hibernate, with all of the Spring transaction > management > > and the Open Session In View interceptor. When I find() an object, I do > > it > > declared READONLY. As all of the properties are updated from the form, > it > > *looks* like everything is changing, but after the cycle completes, all > > changes are rolled back. > > > > If everything works, then I invoke a persist() that will commit to the > > database. > > > > > > > >> -----Original Message----- > >> From: Angelo Chen [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, October 30, 2007 10:58 AM > >> To: users@tapestry.apache.org > >> Subject: Re: T5: Tapestry-Hibernate, do we have to save()? > >> > >> > >> Hi Lasitha, > >> > >> Your thoughts do require some thinking, I'm doing a site now that is > not > >> so > >> critical in the consistency of the data, as it's merely a simple > >> membership > >> database, but if this is to replace a c/s biz application, this will be > a > >> issue, is the current Tapestry - hibernate ready for that? what we need > >> to > >> do in that kind of situation? I asked last time but it was considered a > >> hibernate issue, I like to hear from others too how they manage > >> situations > >> like this? thanks. > >> > >> A.C. > >> > >> > >> lasitha wrote: > >> > > >> > On 10/30/07, Angelo Chen <[EMAIL PROTECTED]> wrote: > >> >> > >> >> is this really needed? I got confused, why the changes are saved > >> without > >> >> calling _session.save()? > >> > > >> > Angelo, this is default hibernate behaviour. See: > >> > > >> > http://www.hibernate.org/hib_docs/v3/reference/en/html/objectstate.html#ob > >> jectstate-modifying > >> > > >> > However, your post brings up an interesting question: will the > >> > object's state be persisted even after validation fails? My first > >> > guess is might actually be a problem. > >> > Consider: > >> > 1. Object is retrieved in onAttached() and associated with a new > >> session, > >> > 2. Fields are updated with values from the form submission (lets > >> > assume they are valid), > >> > 3. Some cross-validation fails in onValidate() - so onSuccess() is > >> > never called, but... > >> > 4. As the thread cleans up, the HibernateSessionManager commits the > >> > transaction anyway and the invalid values are persisted! > >> > > >> > I'd like to test this and look around the lists a bit but am throwing > >> > this out in case others have thoughts. > >> > > >> > Cheers, lasitha. > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > > >> > >> -- > >> View this message in context: http://www.nabble.com/T5%3A-Tapestry- > >> Hibernate%2C-do-we-have-to-save%28%29--tf4718363.html#a13490149 > >> Sent from the Tapestry - User mailing list archive at Nabble.com. > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: http://www.nabble.com/T5%3A-Tapestry- > Hibernate%2C-do-we-have-to-save%28%29--tf4718363.html#a13877665 > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
