ValuesManager doesn't respect setShouldSaveValue?

[bschrameck]

SmartGWT Version: 8.2/LGPL Development Only (built 2011-12-05)
Running on Windows 7 / IE9 / GWT Dev Mode

I have a DynamicForm that contains a CanvasItem with another DynamicForm inside of it. The DataSources for both forms are the same, we just use the CanvasItem for layout purposes. When I save a record I get the following request:

"data":{
    "changeType":"Operator Changes", 
    "leasedSold":"Leased", 
    "storageChange":"No", 
    "isc_CanvasItem_0":"", 
    "changeOfStatusDate":"2012-07-30", 
    "isc_NewButtonItem_0":"", 
    "aircraftId":2
}

I have set the New Button and CanvasItem setShouldSaveValue(false) so I would not expect to see them in the request. We set up our ValuesManager (to combine the two forms) like this inside of the "parent" form:

valuesManager = new ValuesManager();
valuesManager.setDataSource(getDataSource());
valuesManager.addMember(changeTypeForm);
setValuesManager(valuesManager);

On save, we do this:

@Override
public void onClick(ClickEvent event)
{
    if (event.getForm() != null && event.getForm().getValuesManager() != null)
    {
        event.getForm().getValuesManager().saveData();
    }
}

What could we be doing wrong here? It seems like a bug because when not using the ValuesManager (and just submitting the parent form) it works fine, ignoring any fields we set as setShouldSaveValue(false) (obviously our CanvasItem with child DynamicForm is not submitted). I have also tried using a ValuesManager with just the parent form added to it, and I have the same issues as described above: even things with setShouldSaveValue(false) is sent in the save request.

Thanks,
Brian

[Isomorphic]

If you have provided a default value for a field or if you call setValue() / storeValue(), shouldSaveValue:false won't cause that value to be ignored - it will be allowed.

With that clarification, if you think there's a bug here, could you show a test case we can run to reproduce the issue?

[bschrameck]

Hi Isomorphic,

Thanks for the prompt response. I'm afraid the documentation contradicts what you replied with:

A shouldSaveValue:false item should be given a value 
either via defaultValue or by calling form.setValue(item, value) 
or formItem.setValue(value). Providing a value via form.values 
or form.setValues() will automatically switch the item to 
shouldSaveValue:true.

Regardless, I see the issue happening when not setting a default value or using setValue.

As requested, I have attached a standalone test case. It's a modified version of the "Match Value" example in the Showcase. I set the second password field to setShouldSaveValue(false), yet here is what shows in the RPC tab when debugging:

"data":{
        "username":"bob", 
        "email":"bob@isomorphic.com", 
        "password2":null, 
        "createAccount":null, 
        "password":"h"
    }

Also note how the button value is even included. When not using a ValuesManager, the result is this:

"data":{
        "username":"bob", 
        "email":"bob@isomorphic.com", 
        "password":"h"
    }

Thanks,
Brian

[Isomorphic]

We're not sure what you see as conflicting between the docs and what we said, but we'll check on the behavior, which does appear to be a bug.

[bschrameck]

We're not sure what you see as conflicting between the docs and what we said, but we'll check on the behavior, which does appear to be a bug.

The docs say that a shouldSaveValue:false item *should* be given a default value or set with set value, and that only when providing a value via form.values()/form.setValues() will the flag be reverted to true.

A shouldSaveValue:false item **should** be given a value
either via defaultValue or by calling form.setValue(item, value)
or formItem.setValue(value)

You said:

If you have provided a default value for a field or if you call setValue() / storeValue(), shouldSaveValue:false won't cause that value to be ignored - it will be allowed.

Thanks for looking into getting this fixed.
Brian

[Isomorphic]

It looks like you are getting confused between what getValues() would return vs what might be saved - these are distinct. But yes, we're checking on the possible bug.

[ksenia_korenkova]

Hi Isomorphic,
Could you please clarify what was the result of this discussion.Was it a bug?(if yes - was it fixed?)
Does flag shouldSaveValue(false) affects valueManager.saveData() method?Or it is applied only to form.saveData() method.
Currently we use 5.0p.2016-09-19 and it looks like that valueManager.saveData() ignore this flag - all values are saved.

best regards, Ksenia.

[Isomorphic]

There was no bug found, and your confusion seems to be similar to the other poster's: shouldSaveValue works as documented on ValuesManager, including the fact that if you give an item a value via setValues(), shouldSaveValue gets flipped back to true. So if you are seeing unexpected values in saveData(), you should see whether you are populating those items via setValues().

If you think your usage is correct but you are still seeing unexpected things being saved, then we need a ready-to-run, minimal test case showing this behavior, and we can look again at whether there's a problem.