ValuesManager errors using latest 5.1 build

[stonebranch2]

Hi Isomorphic,

We have found another behavioural change after upgrading from "SmartClient Version: v10.1p_2016-06-09/Pro Deployment (built 2016-06-09)" to "SmartClient Version: v10.1p_2016-08-11/Pro Deployment (built 2016-08-11).

Without any code changes, several of our forms are now logging the following, and we are not explicitly setting those values.

[ERROR] [xxxx] - 14:55:36.659:MUP8:WARN:ValuesManager:isc_xxxxFormGenerator_4:Member Form: [DynamicForm ID:isc_xxxxDynamicForm_10] has explicitly specified value for field[s] 'xxxx', but has no item associated with this fieldName. Ignoring this value. Values may be set for fields with no associated form item directly on the valuesManager via valuesManager.setValues(), but not on member forms. See ValuesManager documentation for more info.

Regards

[Isomorphic]

Can you clarify? Clearly the item is ending up with a value and presumably the user didn't input it. So what mechanism in your code supplies the value, and why do you think the resulting warning message is spurious?

[stonebranch2]

The values would be populated via a call to com.smartgwt.client.widgets.form.ValuesManager.editRecord(Record).

This has been working fine, without warning, in multiple releases of SmartGWT; only after picking up the latest daily build for another unrelated fix, did the errors begin. This would imply that something has changed within the last two months within the framework, presumably breaking our implementation. I have yet to confirm any side-effects of the error message, but it is concerning us because this new build has had more than one behavioural change that we've had to make adjustments to workaround.

Regards

[Isomorphic]

Actually so far it looks like all 3 of your threads today may have exactly one bugfix as the cause: we fixed setValuesManager() so it actually works, and your implementation may have relied on it doing nothing before. We'll come back to that in your first thread, but as far as this error message..

1. are you saying that a call to editRecord() produces this message based on values that are present in the Record, and not provided by any other means?

2. have you definitely eliminated any possibilities such as your event handlers firing and populating values directly in form items?

[stonebranch2]

1. When we perform an UPDATE operation. The ADD operation does not produce the warnings. On the surface, it would appear that every field that is in the record, that doesn't have a form item representing it, produces a warning. It floods the SmartGWT Developer Console with those errors.

2. If we revert the v10.1p_2016-06-09 build, the errors do not appear; so at the moment, we are running with the fact our code was constant, the libraries were not. Perhaps our code is doing something that your recent changes are not expecting, that up until now, was not an issue.........

On that note, I just discovered what that "something" is.

We have cases where we have a DynamicForm member variable. Here is some "fake" code to demonstrate the scenario.

public class XYZFormGenerator extends AbstractFormGenerator {
    private DynamicForm someForm = new XXXDynamicForm(...);

    public void addToLayout(Layout layout) {
         layout.addMember(someForm);
    }
}

The above structure above produces the errors, the structure below does not appear to, although I need more time to completely verify.

public class XYZFormGenerator extends AbstractFormGenerator {
    private DynamicForm someForm;

    public void addToLayout(Layout layout) {
         someForm = new XXXDynamicForm(...);
         layout.addMember(someForm);
    }
}

It is possible, the change in initialization logic with respect to the setValuesManager might also be the culprit here too.

Regards

[Isomorphic]

SmartGWT wouldn't even be aware that you held onto the form in a variable. Probably this change in your code changes the timing of other calls.

[stonebranch2]

The point was mainly that your change has enforced an initialization timing that clearly wasn't a requirement before. It wasn't necessarily the fact the form was held as a variable but rather when that variable would have been initialized. We will work around this of course but we were clearly impacted in multiple areas by the set values manager fix you've made recently.
Regards

[Isomorphic]

So again, please wait for our response in the first of your 3 threads. We didn't shift initialization timing, we fixed an API that was effectively no-op'ing. We will need to figure out whether there is a legit backcompat concern here, or whether you were basically calling a nonfunctional API and can simply remove your calls, or replace them with correct usage.

[stonebranch2]

Thanks for the update. We will move fwd with changes to keep compatible with the current expectations out of necessity and await any updates on the original thread, making any adjustments in the future as neccesary.
Regards

[stonebranch2]

Hi Isomorphic,

While we have dealt with most warnings, we are still struggling with warnings when we have multiple DynamicForm's associated with a ValuesManager.

10:09:41.652:MUP0:WARN:ValuesManager:isc_xxxx_0:Member Form: [DynamicForm ID:isc_xxxxDynamicForm_0] has explicitly specified value for field[s] 'xxxx', but has no item associated with this fieldName. Ignoring this value. Values may be set for fields with no associated form item directly on the valuesManager via valuesManager.setValues(), but not on member forms. See ValuesManager documentation for more info.

Have you made any changes or decisions relating to your recent fix with the ValueManagers that might assist us here? This is becoming a blocker for us.

Thanks

[Isomorphic]

We're reworking our fix to DF.setValuesManager() right now and will update here when it's fixed.

[stonebranch2]

Thank you kindly for the update.

[Isomorphic]

This reworking is now in place - let us know if you still see issues in builds dated August 25 and later

[stonebranch2]

Thank you, we will verify when the build becomes available.

[stonebranch2]

Hi Isomorphic,
So far so good, will let this go through some rounds of QA and follow up if anything comes up in the future.
Thank you again