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.
I can't tell you how many times I have seen this one to many relationship
web interface all choked up with "temporary" saves to the database or
session that somehow have to be purged if the user closed their browser,
canceled their edit or just navigated away from the form.
The delete method is the same as the add, it is just working on the
collection in memory. So the end result of the users actions are saved.
The post method can be ignored. It was just a way for me to be sure that
all of my fields where named correctly without having to add or delete a
row. Hint: If my field or variable names were messed up then some of the
fields in the rows would come back with default values rather than what was
there before the post.
_D
Rob Hills wrote:
>
> Hi Dusty,
>
> On 13 Nov 2007 at 21:02, dusty wrote:
>
>> So it doesn't happen that often, but it just so happens I wrote what you
>> described today! ;-)
>>
>> You create a table with each row representing your child objects. Each
>> html
>> element should have the name
>> parent.child[%{row.index}].childpropertyname.
>> The row part comes from <s:iterator status="row">
>
> Thanks for the detailed description of your elegant solution. I have one
> thing
> to clarify to try and fit it to my case. I note from your code that "Add"
> and
> "Delete" actions on your equipmentCart list have their own methods on the
> action and that your "postCart" action simply returns a status flag.
>
> In your example, I'm guessing that add and delete actions each occur
> within
> their own transaction, is that correct? If you had a Parent record in
> this
> example, and some changes were made to that parent record, and the user
> added and deleted some children, and then decided to cancel, would the
> child record changes also be rolled back?
>
> TIA,
> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/AppFuse-2-%2B-Hibernate-%2B-Struts---Master-detail-form---update-master-and-detail-data-in-one-transaction-tf4802043s2369.html#a13749160
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
