View Full Version : Resetting BeanModel on editor dialog cancel

22 Nov 2011, 2:44 PM
I have a BeanModel that I am displaying in a panel that I pass to a pop-up dialog for editing. If the user cancels the edit dialog I want the BeanModel to revert to its original state, but I am having trouble getting this to work.

Is there an example out there that implements this?

It seems that there are two possibilities.

First, what I thought should work was calling setUpdateOriginalValue(true) on my FormBinding object and then calling reset() on my FormPanel object when the dialog is cancelled. However, that doesn't seem to work for me. It doesn't appear that the reset() method on the field is firing the onChange event and mapping the reset value back into the BeanModel. So I suspect I'm doing something wrong. An example would really help.

The second option, would be to clone my BeanModel, pass the clone to the dialog and only copy the results back to the original BeanModel if the user clicked Save. However, I haven't found any examples of BeanModel cloning either. Assuming my POJO implements clone(), is this all I need to do?

BeanModel beanModelCopy = BeanModelLookup.get().getFactory(beanModel.getBean().getClass());

I am interested in the answer to this question even if there is a way to make the first option work for this case.


23 Nov 2011, 6:28 AM
I had this problem for a looooog time, I followed your "second" option finally. My binding is done such that at the initial point as well as when reset/cancel is invoke, a new BeanModel of my POJO is created and bound to the form (or whatever it is). This is also needed when the form has been submitted and U want to "clear" the values (which actually mean clearing the bound BeanModel) for fresh entries, especially when the form has some optional fields that may have been filled during the previous entry.

I considered cloning, but the nuances of the clone() method in Java made me look elsewhere.

protected Object createModelStub() {
return GWT.create(Loan.class);

23 Nov 2011, 11:27 AM
Thanks for the feedback. I will pursue option 2.

About the clone bit, thinking about it last night, I surmised that the clone approach is wrong even without getting into the general issues around Java's clone. Because when I do want to save, then I need a process to copy the contents of the beanModelCopy back into the original beanModel. If I have that method, then I can just use it to the contents from beanModel to beanModelCopy in the first place.

I also realized that switching from implementing BeanModelTag to extending BeanModel makes all of the copying code a lot simpler. The fact that it also makes the templating (i.e. generics) for some of my custom widgets clearer means the switch is a win-win situation.

Thanks again.