Hey Rob,
#1 Can you show me your cancel button? In Appfuse, the Cancel button is
actually a submit button that sends the form to your save method. If your
Action extends BaseAction it should catch the cancel and abort the operation
and return CANCEL. If for some reason you did not extend BaseAction or your
button's name is not method:cancel then it will just go through to your save
method. If that is not the case then its possible that your collection is
getting persisted based on something in your add method....
#2 This is usually due to the Spring configuration for transactions and your
manager method names. It depends on what version of Appfuse. The latest
version of Appfuse lets all methods be read-write, but in the past methods
that started with get were marked as read-only and if I remember its
possible that only methods that start with save* can have a read-write
transaction. But in my experience this is where this error comes from. Let
me know what version of Appfuse and put up your Spring configuration so I
can take a look. Also let me know what the Manager method name you are
calling.
#3 Remove
The delete link includes the id of the child. So on the web page you have
a link like this:
<a href=javascript:remove(index)>
Then you need a javascript function like the others that changes the action
of the form to point to your Webwork delete action method.
function remove(index){
var form = $('myformid'} //using the prototype library $() funciton
form.action = 'removeurl.html?index=' + index
form.submit();
}
Finally in your Action you need an int setIndex and index variable to accept
the url parameter. In your remove method you use this int to find the child
in the current parent collection. Then you check if this child has been
previously saved, so you can delete it from the database before you remove
it from the colleciton.
public String remove(){
Child child = parent.getChildren().get(index);
if(child != null) { //guard against some bad index number being
passed
if(child.getId() != null){
childManager.remove(child.getId()) //or something like that
}
parent.getChildren().remove(index);
return SUCCESS;
}
Rob Hills wrote:
>
> 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]
>
>
>
--
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#a13774824
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
