Rob,
Its probably that time where you zip up the relevant code and ship it off to
me. [EMAIL PROTECTED]
It will be easier if I just take a look, if you'd like me to.
-Dusty
Rob Hills wrote:
>
> 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]
>
>
>
--
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#a13794976
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
