Questions about FormModel.isDirty()

[cyboc]

I've got some questions about FormModel.isDirty(). I apologize in advance if I'm stupid or if I missed something obvious in the javadocs, the user manual or the code.

On this page, http://forum.springframework.org/showthread.php?t=10914,
I was given this advice about my View that has a tree on the left and a "edit the selected tree node" form on the right:

If the user makes a selection and the current formmodel is dirty, commit the changes.

The tree is initially loaded with countries, provinces and cities that are stored in a database. When the user selects one of these nodes (for example, a country node), the details are shown on a form on the right, where the user can edit the values, if desired. Before I show the form to the user, I call myForm.setFormObject(mySelectedObject).

Now I noticed that just before the setFormObject call that myForm.getFormModel().isDirty() returns false and after the call it returns true! To me, that just doesn't seem right because the user hasn't made any changes to the values yet.

When I look at the implementation of DefaultFormModel.isDirty(), I understand what is happening. Here is that implementation:

public boolean isDirty() {
    if (getFormObject() instanceof FormObject) {
        return ((FormObject)getFormObject()).isDirty();
    }
    else if (getBufferChangesDefault()) {
        Iterator it = displayValueModels.values().iterator();
        while (it.hasNext()) {
            ValueModel model = unwrap((ValueModel)it.next());
            if (model instanceof BufferedValueModel) {
                BufferedValueModel bufferable = (BufferedValueModel)model;
                if (bufferable.isDirty()) { return true; }
            }
        }
    }
    return false;
}

My domain objects in the tree do NOT currently implement FormObject. Therefore, the actual isDirty check gets delegated to BufferedValueModel.isDirty(). Ultimately, this isDirty check boils down to the result of this comparison: bufferedValue != NO_VALUE. When BufferedValueModel is instantiated, bufferedValue is initialized to NO_VALUE. However, as soon as you call myForm.setFormObject(), this causes BufferedValueModel.setValue() to be called, which ends up setting bufferedValue to a value that is not NO_VALUE. Thus, the state of the dirty flag is not affected by user editing. To me, this just doesn't seem right; isDirty() should return false until the user edits the values.

Of course, I could make my domain objects implement FormObject so that I could have complete control over the isDirty logic but I'm somewhat reluctant to create a dependency between my domain objects and a GUI framework.

Questions:
1) Is there a workaround for the current isDirty behaviour?
2) Can isDirty be changed so that it only returns true when the user has actually edited a value?

Cheers,
Joe

[Keith Donald]

Good catch. I agree, implementing FormObject is discouraged in most cases. This is a bug in BufferedValueModel I will fix.

[Keith Donald]

The problem was in the AbstractValueSetter related classes in the forms package. Give it a shot now.

[cyboc]

Thanks a lot Keith. Man I can't believe how fast your response time is. Anyway, the new version of the file is not showing up yet in anonymous CVS. I'll check again in a few hours and I'll let you know the results.

Thanks!

[steve_smith]

Of course, I could make my domain objects implement FormObject so that I could have complete control over the isDirty logic but I'm somewhat reluctant to create a dependency between my domain objects and a GUI framework.

Why wrong to implement FormObject? I think is good.

[cyboc]

Why wrong to implement FormObject? I think is good.

I'm not saying it's wrong. I would just prefer not to do it for the reason of preserving better separation of concerns. IMHO, domain objects should try to model an entity in your business. In my example, I'm trying to model countries, provinces and cities. If I were trying to model an entity called Laundry Item, I might think about adding an isDirty() method.

In addition, implementing FormObject in a domain object means that your object now has a dependency on the Spring Rich Client framework, which is mostly meant as a GUI framework. Domain objects should be independent of any particular GUI framework. For example, I might choose to deploy my domain object in a web framework (like Spring Web) that knows nothing about FormObject.

Anyway, Steve, it's not wrong, I would just not prefer to do it. It might work well for you though. It's really up to you.

Cheers,
Joe

[steve_smith]

Okay, this makes sense for me. Thanks for answer. :P

[Keith Donald]

So Steve this is what you do with your time since you broke your leg in week 2?

Sorry, Carolina panthers football fan, couldn't resist :-)

[steve_smith]

Oh yes, Steve Smith is Carolina football player, no? My real name is Stefano Rossi, sort of Italian version of American Steve Smith name. LOL. My friends call me Steve Smith as joke.

For me, American Football is good but I like "real football", what you call soccer.

Okay for now.

[cyboc]

I hate to get off topic here but I can't stand idly by on this one. Football and soccer are okay, I guess, but HOCKEY is the best sport! (Having said that, I did very much enjoy seeing the Red Sox embarass the Yankees!)