Best way to put bound, calculated fields on a form?

[klrodgers]

I need to put some display-only fields on my form that are calculated from user input and domain data. I want the calculated fields to be "bound", in the sense that they should get the usual converters, binder/binding, interceptors, etc, even though there are no corresponding properties on the domain objects. Also, when I set them, the form should not get "dirty".

What's the right way to make a ValueModel for these fields?

I read in another thread (which I cannot seem to find now), that these fields should be in "another" form model. Ok, I created a separate form model and an object for it to introspect (fine so far), but then it was a mess getting them bound (had to create another binding factory), and put into the TableFormBuilder (add(Binding); gets assertion failure). So I copied the code that adds the label+gap+bound component to the layout. Then when a valueChangeListener fires, I set a new instance of my "bean" into the separate form model.

It seems to work fine, but it's quite a bit uglier than I expected, specifically in the binding and form building parts. The extra "bean", listening on value model edits, and replacing the bean is all very nice. But I must be off-track if it is so hard to get a bound component layed out, right?

Thanks,
--kerry

[lstreepy]

Hi Kerry,

Help me understand a little more about your problem. Why do you need all the "converters, binders, etc." if this value doesn't map to a property on a domain object?

If this is in essence a display-only property, then there are better ways to handle this.

Obviously I'm missing something from your application requirements.

Thanks,
Larry.

[hammer]

If this is in essence a display-only property, then there are better ways to handle this.
Larry.

so if the display-only property does not belong to the domain object , what are the better ways?

[lstreepy]

Well, the simplest is to just place a label (or whatever component you want to use to display the calculated value) on the form. Register a value change listener on the properties that are used to calculate the value. In that listener, grab the current property values, calculate the display value and change the text on the lable to present it.

I've posted a helper class on this forum (somewhere) called AbstractValueChangeMonitor that makes this wiring pretty simple.

Larry.

P.S. I have been giving some thought to creating support for "virtual/derived" properties in a form model, and that would essentially create a property that the form would think is (a read-only) part of the domain model object. Thus it would be treated just like any other property. I don't know when I'll get to this, but it's an obvious extension to the need discussed in this thread.

[klrodgers]

Thanks Larry. I wrote a long, convoluted followup, then decided it wasnt very helpful until I tried some more code. Then I got sick and didn't code But your response to hammer's question is right on.

Larry, when you say "just palace a label...on the form", do you mean something like (from memory):

JLabel l = new JLabel();
formBuilder.getLayoutBuilder().cell(l, "...");

This makes my label (or whatever) look and act totally different than others on the form, because it didn't get any of the treatments done in binders and interceptors.

What you say in your PS is exactly what I was thinking of.

For the moment, I introduced a fabricated domain object, linked it into the form model's object, and then deleted the ugly code that put this fabricated domain object into a disconnected form model. This works fine for now.

I'm not sure it will keep working fine when I try to implement the requirement to update fields asynchronously from the back-end while the user may be editing, but I'll cross that bridge when I come to it.

Thanks again, Larry.
--kerry.

[hammer]

I introduced a fabricated domain object, linked it into the form model's object.....
I'm not sure it will keep working fine when I try to implement the requirement to update fields asynchronously from the back-end while the user may be editing,...

I think the "fabricated domain object" you introduced is something like a DTO,so you can add any properties to the DTO for the purpose of matching your GUI need.

And to handle the user's editing some fields that related to the caculating,you can add some value change listeners on the related properties,like the following code in a form:

addFormValueChangeListener("relatedProperty", new PropertyChangeListener()
{
    public void propertyChange(PropertyChangeEvent evt)    
    {    
        //do caculation...;
        //getValueModel("result").setValue(result);
    }
}
);

[Demo]

As Larry mentioned above he write a helper class posted here http://forum.springframework.org/showthread.php?p=43651

Meanwhile I use this helper class for some calculations and dependency values. For example, the entered Zip-Code automatically proposes a correspondig place, 1111 --> A place. The advantage of the AbstractValueChangeMonitor is that you have access to both the old and new value.

In my opinion it depends on the moment, when you want to execute your calculation. The AbstractValueChangeMonitor intercepts all key strokes. Sometimes it is adequate when you do some calculation when your field looses the focus or a specified key, such as Return, is pressed.

markus