FilterBuilder resets value when operator is changed.

[stonebranch1]

Is the expected behaviour to reset the value within a FilterBuilder when a different operator is selected?

If so, is there a property to retain the value across operators similar to the property to retain the value across fields?

SmartClient Version: v9.1p_2014-07-06/Pro Deployment (built 2014-07-06)

[Isomorphic]

In general, the FilterBuilder will clear values that are clearly inapplicable to a newly chosen operator, or just very likely to be inapplicable.

Which particular operator to operator transition is dropping values where you'd prefer that they be kept?

[stonebranch1]

When flipping amongst these operators:

contains, starts with, ends with, equals (and their not versions)

I was expecting the value to be maintained.

Also amongst these operators:

less than, greater than, less than or equal to, greater than or equal to, equals, not equals

[stonebranch1]

The Text item blanking out might be my fault as I am over-ridding getValueFieldProperties and the form item for text types is setting the value to null.

Just trying it out now.

[stonebranch1]

Yeah the problem is that by over-ridding getValueFieldProperties and returning my own FormItem causes the value to be empty when the operator changes.

Is there anyway I can maintain the value in this case?

Since the value is not passed into the method (and i can understand why), I cannot set the value directly on my newly created FormItem that I return.

[Isomorphic]

You could look at the current value of getCriteria() right before the FilterBuilder calls getValueFieldProperties() and provide the value for the current fieldName as a defaultValue on your FormItem.

[stonebranch1]

Sorry, I am not quite following what you are saying.

Are you saying in my over-ridden getValueFieldProperties() I should call getCriteria() or were you being literal and I should somehow call getCriteria before my over-ridden method is invoked?

If it is the first case, then I am not sure how I would find the correct criteria out of the AdvancedCriteria returned by getCriteria(). I am assuming this AdvancedCriteria would be the entire criteria currently defined in the FilterBuilder which would cause the problem that the same field could exists for multiple criteria definitions.

If it is the latter case, how would I "look at the current value of getCriteria() right before the FilterBuilder calls getValueFieldProperties()". Not sure how to achieve that and would the same issue arise as above w/r AdvancedCriteria and finding the correct one?

[stonebranch1]

I narrowed down the problem to this call:

setRetainValuesAcrossFields(Boolean.FALSE);

I set that to wipe out the value when you change the field and the doc 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."

However it is causing the value to also be wiped out when just the operator is changed (not the field).

[Isomorphic]

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.

Right now, for both field change and operator change, we use the same rules. From the code comments:

// Clear out the currently entered value if
// 1) the valueField data type has changed
// 2) the new valueField has a valueMap and the current value doesn't appear in it
// 3) either the old or new field has a valueMap or optionDataSource

This seems like it is already an intuitive and useful behavior.

[stonebranch1]

The rules seem fine but I do believe there should be separate properties to allow for fine grain control and allow for the keeping values across operators w/r to the rules but to always clear the value if the field changes.

[Isomorphic]

Sorry, that would be non-trivial to implement, and again it just seems worse. Values from one field very frequently make sense to use with another field and the existing rules seem to strike a good balance for whether to keep values or not.

If somehow, in your app, this behavior is imperfect, we'd recommend Feature Sponsorship as the way to get this added.

[stonebranch1]

I disagree that values from one field would make sense to retain for another field. Typically different fields contain completely different data and it most of the times it makes no sense to keep values between fields and hence your api that states it will retain or not retain values between fields. No where does it imply this pertains to operators too and why would you want to wipe out the value when all you did is change the operator say from starts with to contains?

Why did you say "We could do something like introduce a separate property for whether values are retained when the field changes vs when the operator changes" and then when I agree that I think that would be the right thing to do you then say it would be non-trivial to implement and say it seems worse.

[Isomorphic]

I disagree that values from one field would make sense to retain for another field. Typically different fields contain completely different data and it most of the times it makes no sense to keep values between fields

It's not uncommon for fields to contain closely related data (eg subject vs message body, job title vs department, etc), and the more important concern from a UI perspective is whether it's worse to throw away user input vs require the user to delete their old input.

It's quite dismaying to have the UI throw out long word or phrase that you actual want to re-use. It usually takes negligible effort to get rid of a value you didn't want to keep.

Also consider the context of input in the FilterBuilder: 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.

..why would you want to wipe out the value when all you did is change the operator say from starts with to contains?

Quite right! That's why it's not the default behavior. And what we suggest is restoring the default behavior, which also retains values across fields, which we also think is the right behavior.

Why did you say "We could do something like introduce a separate property for whether values are retained when the field changes vs when the operator changes" and then when I agree that I think that would be the right thing to do you then say it would be non-trivial to implement and say it seems worse.

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.

And just for completeness: as explained above, we believe the default behavior (retain values across *both* operator change and field change) is better than your proposed behavior.

[stonebranch1]

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

I don't see how an all or nothing (wipe out the values for both field & operator or keep for both) is better than having the flexibility for the user to decide by having a property for each one independently.

Do you honestly believe that, really?

Anyone can spout off a couple of related data examples. I can spout off tons of non-related field examples as well, what does that prove. I know in our complex set of data and tables, very few fields have any commonality of the data they keep that would makes sense for use to retain values between them and just because we do not want to retain values between fields in no way implies we do not want to retain values between operators!

All I know is our current users complained that the value was retained when they changed fields and when we set the property (again that does not state it applies to operators that I could tell) to not retain, they then complained that the value was being wiped out when they changed operators.

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.

Guess I can tell them that you know best though.

[Isomorphic]

I don't see how an all or nothing (wipe out the values for both field & operator or keep for both) is better than having the flexibility for the user to decide by having a property for each one independently.

Do you honestly believe that, really?

No, we haven't said anything on this 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.

Guess I can tell them that you know best though.

You can tell them whatever you want, but we'd suggest the truth: you asked for a free enhancement, but we weren't willing to do it for free because we disagree with your design.

We have, elsewhere, added tiny enhancements on your behalf even though this goes well beyond Support. A bit surprised to see a snide comment here after all of that.

Regardless, you aren't stuck - sometimes, a reasonable default behavior is just the wrong thing in a very specific circumstance in a particular application. The Feature Sponsorship program exists so that you can get a narrowly applicable feature like this added.

So, the difference between the users you've talked to and the users we've talked to might be that your users did not consider or did not experience this:

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.

.. but if you think otherwise, if you think it's not at all a 50/50 call within your app and very important to correct - Feature Sponsorship is there as a solution.