Hi Dusty, On 14 Nov 2007 at 7:44, dusty wrote:
> That is the beauty of this solution. There is no transaction until the user > decides to save the form. Imagine a form with a series of fields and then > this table at the bottom. They are all part of the same form. When I > submit the form to my add method on the action, the action reconstructs the > objects for me , adds a element to the collection and then returns it all > back with no touch to the database. So the user is just filling out the > form as they normally would and when they click save at the bottom of the > form you post your form again but this time to a save method. The save > method just saves the parent and if you have some hot cascade action going > then the children are saved along with it. No looping, no mess. Hmmm, I've tried implementing things by extrapolating the code you sent in your previous email, but I'm running into problems. I can add child records, but those are persisted after I cancel from the main form. Also, when I try and save, I get a weird hibernate error "write operations are not allowed in read-only mode (FlushMode NEVER/MANUAL) - Que? I've checked all the model classes and annotations and can't see anything wrong. I'm using a GenericDao for both parent and child records and calling the parent DAO's save method so maybe I'll have to roll my own DAO's to either fix that problem, or at least get better visibility :-( Finally, I'd like to see your "remove" method - I can remove my child records OK, but I'm having trouble returning to my original edit screen and am wondering what's the best way of doing that. Cheers, Rob Hills Waikiki, Western Australia Mobile +61 (412) 904-357 Fax: +61 (8) 9529-2137 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
