I'm using almost the same pattern as you, I've created an interceptor that loads the model in the action (detection of the id paramter and extension of the ModelDriven interface to add setModel(..) and getModelClass() method, thus I can load and store easily my entity in my ModelDriven action). It works really great.
The only problem is the following one : 1/ My model is populated in my interceptor 2/ The validation interceptor finds errors on my model 3/ How can I elegantly "rollback" the changes made on my model whithout Hibernate saves the change in db when closing the session, in the after method? Should I call session.refresh(...)? Keep the Transaction open until I can rollback it in the after() method in case of errors ? Any help appreciated. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Anoop Ranganath Envoye : mardi 7 octobre 2003 17:57 A : [EMAIL PROTECTED] Objet : [OS-webwork] UPDATED: hibernate/webwork2 best practices Well, I wrote this description of how I was doing things about three weeks ago. I mentioned that something didn't smell right about this technique. It wasn't necessarily wrong, it just seemed that there should be a better way. Well, I think I found it. It's very clean, provides excellent separation between persistence and logic, and makes actions even more POJOish. I set up interceptors for our domain objects. In the before() I open a hibernate session, load the appropriate objects, and put them on the action. in the after() I check if the action has any errors, and if it doesn't, I flush the session and then I close it. The beauty is that the actions only manipulate the objects. Since the hibernate session is open, the changes to the objects are automagically persisted when it is flushed without having to call saveOrUpdate(). Actions become very, very testable. Also, I put this interceptor in _after_ the component interceptor, so I can fairly easily grab any components I want to use off of the action. In this case, the HibernateSession and DAO. This is definitely a hack, cause ideally, the action shouldn't be aware of them at all, but it's a poor man's way of using IoC in the interceptors. So far this has proven to be an excellent way of doing this. There are a few caveats however. Exceptions getting thrown from interceptors disappear into oblivion. Right now, I just catch all exceptions in the intercept() method, and add them as action errors. The second caveat is every call to an action results in a database hit. I'm sure there are ways around this, but for our purposes Any comments? Anoop On Tuesday, September 16, 2003, at 11:31 PM, Anoop Ranganath wrote: > I just started using WebWork2 yesterday, and I'm sold. A new > techonology hasn't kept me smiling for so long thinking "this is > right" since I first started playing with Ruby. > > I'm writing a vanilla database backed webapp for my client, and I'm > trying to decide where I should put the persistence code within the > WW2 framework. Right now I've implemented the Thread Local Session > seen here ( http://hibernate.bluemars.net/42.html ). I created a DAO > which uses the Thread Local Session to retrieve and persist the > business objects. I've made the DAOs components on the session and > any actions that need them are enabled for the DAOs. > > The thing is this seems clunky to me. I've only been using the > framework for two days, but something about this approach doesn't feel > like I'm fully leveraging WW's capabilities. I can't quite get my > nose on the smell, but it's definitely there. > > Any ideas? I'm sure this is a problem that's been solved many times > over. > > Anoop > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
