Hi Dusty,
dusty wrote:
#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....
The cancel button is indeed a submit. My action extends BaseAction and
I have a save() method in it that checks for cancel first up and returns
CANCEL. I actually think the problem with the collection has occurred
long before then, because if I add an item to the collection, I see it
in the DB before I click the save button on the parent record. I have a
feeling that this problem is probably a symptom of problem 2.
#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.
I'm using AppFuse 2.0 and I've not had any problems with any of my other
forms FWIW, though none are as complicated as this one. The Action I'm
using to add my child record is named "addChild". My Spring
configuration is much the same as for all my other objects (except that
it has an extra "addChild" action defined) and the only changes I've
made to it are to include my own classes (DAOs, Managers, Actions etc)
where I'm using those instead of Generics.
#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;
}
Thanks for those details. I actually got my delete working - because I
was using a get (ie a URL with parameter) rather than a Post, I wasn't
getting my Parent ID back to display the updated parent record. I
simply used code like that which you've shown above to retrieve the
child record and then used its parent record (before I removed it) to
pull the Parent back. Interestingly, this seems to be working properly
in that after I delete a child record, the form shows the updated state
(ie with the child deleted) but the child hasn't yet been removed from
the DB. If I can work out what's causing the transaction error on post,
I think I'll have it sorted.
I suspect my problem is to do with some of the subtleties of mapping
relationships between POJOs using Hibernate annotations. I seem to
remember reading about this kind of problem before - something to do
with having to specify a one-to-many relationship in a special way to
work around an "undocumented feature" in Hibernate, but I can't find it
now. Currently I have a "bi-directional" relationship with a
not-nullable constraint on the parentID in the child record and my
recollection is that you have to hold your mouth right when you do the
annotations for this or it won't work. I'd actually prefer to have it a
one-way relationship but I haven't worked out the right annotations for
that yet.
Cheers,
Rob Hills
Waikiki, Western Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
