[stonebranch1]

I am getting confused here because I keep getting 2 different statements from you unless I am misunderstanding what you are saying.

You seem to say that having 2 properties does not make any sense and that having just the one that exists now is the best way and that having 1 instead of 2

is better than your proposed behavior

and then when I ask you about that you then say

No, we haven't said anything on this one way or another.

but you just did. You said quite clearly that the default behavior is better than what I propose (having 2 properties) and then you turn around and deny that you said anything one way or another.

We don't really have an opinion about one flag vs two separate flags because to us, and to the users we've talked to, all combinations of setting those flags would be worse than the default behavior.

So what users are these that would not prefer more flexibility? This could certainly be done in a completely backward compatible way so that the existing behavior remains as is but by setting the other property explicitly
would allow for full control and customization. So how could that be worse when you would still have the default behavior and also have the ability to control both?

The api documentation should at least be changed to state that not only fields but also operators are affected.

I have appreciated very much the help and fixes and changes you have made but there are times that the responses coming from you are ... lets just say unexpected

[Isomorphic]

Not sure how we can make this any clearer, but we'll give it one more shot.

The default behavior is what we recommend.

The default behavior is what is preferred by the users we have talked to.

We're not interested in adding additional flags to the framework to control this behavior, for the simple reason that the default behavior (when no flags are set at all) is the behavior that we consider the best, and that the users that we have talked to also consider to be the best.

But again, if your particular users when using your particular application strongly feel that a different behavior is desirable, you have Feature Sponsorship as a means of having additional properties introduced so you can get the behavior you want.

We hope that, re-reading previous posts, you will be able to see that we've been saying this same thing all along. And further, that each time you have become frustrated, you were reacting to something we never said at all.

[stonebranch1]

I do not disagree with the default behavior and I have never said it should be changed in any way however I expect an api named "setRetainValuesAcrossFields" that clearly states

Dictates whether values entered by a user should be retained in the value fields when a different field is selected. Default value is true.

Note that, when switching between fields that have an optionDataSource or valueMap, this property is ignored and the values are never retained.

to do just that and not change the behavior of what happens when I change the operator (not the field).

[Isomorphic]

We agree that the documentation could spell this out, but the behavior can't be changed - other people are using this capability, and the way they use it (which is a very unique edge case - not really a normal FilterBuilder at all) the value does always need to be dropped.

So while we may expand on the docs (and even tell people not to use it for normal FilterBuilders, explaining the UI drawbacks as we have here!) this doesn't help your situation.

This is a really minor nit to still be arguing about. We'd really encourage you to either:

1. take our advice, forget about a new behavior, and explain to your users that the default behavior is also reasonable. Again your users might not have considered this scenario:

if the user typed something into the value area and then needs to change the field, they probably had the field wrong and the input they typed in was intended for the field they are changing to.

2. just use Feature Sponsorship. It's less expensive, in terms of typical developer time, than this protracted discussion has been.

[stonebranch1]

I will take it forward to our CTO and see how he wants to proceed.

However, I have never once implied changing any existing behavior what so ever so I don't understand why you keep stating problems with people using it as it is now.

All I ever wanted was for a 2nd property that would control the behavior of the operator changing w/r the value field. This would only change the current behavior if called so would not affect any existing code/users since they are not setting the new property.

It really does not change any behavior of any code already in existence and only provides an extra level of control and customization of the FilterBuilder behavior.

And I also want to make clear that you originally suggested this

We could do something like introduce a separate property for whether values are retained when the field changes vs when the operator changes, but first, please consider whether you are actually improving on the default behavior.

and when I agreed that would be very good and solve the issue, you came back and said

Sorry, that would be non-trivial to implement, and again it just seems worse.

which I found confusing and then you followed on with

the default behavior (retain values across *both* operator change and field change) is better than your proposed behavior.

so I hope you can understand why I was getting frustrated over this issue

[joeljiao]

setRetainValuesAcrossFields(Boolean.FALSE) is not working for 2nd level filter

2nd level filter value does not get cleared and this has been a big problem for our project when changing field name, it works only
for 1st level filter, please help, see attached image

[Isomorphic]

so I hope you can understand why I was getting frustrated over this issue

We already explained what we meant by "we could" and apologized for the confusion:

Sorry if you thought this was an offer to actually implement a new feature. It's very common to use the phrase "we could" to indicate a possible approach, and that's all that was meant here.

.. so we were hoping to see you return to a non-frustrated state at some point..

Just trying to reset this to a non-contentious discussion. This is a very ordinary circumstance with no-one being unreasonable:

1. you're looking for a new feature to be implemented

2. we're declining to do it for free. We sometimes implement tiny features for free even though it's clearly going beyond the Support service. In fact we've done so for you and we're in the process of doing so for you on another feature. But we only do this kind of thing for a widely useful, very trivial and safe change, and this proposal doesn't meet that standard in our opinion.

3. Feature Sponsorship is a great way to get small enhancements like this done. Many customers set up a small retainer with us for doing these kinds of small enhancements, since a tiny enhancement to the framework can sometimes obviate a lot of application code.

We'll check on the (other poster's) report of retainValuesAcrossFields not propagating to subclauses.

[joeljiao]

I am really looking forward to it.
It does not seem to do with browser, but for my testing,
I used fire fox and chrome.

Thank a lot !!!!

>>We'll check on the (other poster's) report of retainValuesAcrossFields not propagating to subclauses.

[Isomorphic]

The issue with retainValueAcrossFields not propagating to subclauses is fixed for tomorrow's builds.

[joeljiao]

Thank you for such quick fix, looking forward to it!
Would you please post a link for the new build to download as soon as it is done?

[Isomorphic]

It will be at smartclient.com/builds in a few hours, dated 2014-08-11