Possible? to make betweenInclusive operator customizable?

[martintaal]

Hi,
I see that the betweenInclusive operator (...) is hardcoded in several locations in the smartclient code.

I would like to use a different operator. This is not possible currently.

Would Isomorphic be willing to make this operator customizable by putting it in a constant somewhere?

gr. Martin

[Isomorphic]

Are you talking about the allowExpressions feature of the FilterBuilder, or something else?

What would you use as a replacement for "..."? Are you aware that "..." is used in several similar expression languages that users may be familiar with, and do you have a reason to believe you've got an operator choice that more users would be familiar with?

[martintaal]

Ha, sorry for not being more clear, yes the filterbuilder.

We have a user experience expert who finds (through experimenting with users) that the minus/dash (-) is more intuitive. I understand that the dash is also used as the minus sign in numbers. Still that is less important for this case.

So therefore this request which seems relatively simple (I hope).

gr. Martin

[Isomorphic]

The other, even more major problem being that "-" is far too common of a character, creating ambiguity. We're going to have to politely disagree with your user experience expert here :)

[martintaal]

Yes, I kind of expected this, so I am not looking for the range character to be changed, but to have it configurable, it is only used on like 5 locations and it can make sense to put static strings like this in a constant in any case, just my 2 cents.

gr. Martin

[Isomorphic]

Right, to elaborate, there's no other string we can imagine it being changed to, certainly not "-", so we didn't bother with making it configurable. If you really think it's important, feel free to submit a patch - you seem to basically know what code needs changing.

[martintaal]

Hi,
I checked it and to make it configurable all the search/operator symbols should be made configurable (at least that's the nicest), this is a bit too much/risky for me to do. So we will live with the ...

One other request though, the current implementation allows only and/or logic in specific types of fields. It would be great if this can overridden on FormItem level.

I made a patch for this, it is a small one in FormItem.js. Based on nightly of 8.1 from 9th of september.

I hope you will consider it.

Let me know if another format than diff is more suitable to provide patches.

@@ -11425,11 +11425,7 @@
 
     
     parseValueExpressions : function (value, fieldName) {
-        var type = this.getType(),
-            isValidLogicType = (isc.SimpleType.inheritsFrom(type, "integer") ||
-                isc.SimpleType.inheritsFrom(type, "float") ||
-                isc.SimpleType.inheritsFrom(type, "date")
-            ),
+        var isValidLogicType = this.isValidLogicType();
             opIndex = isc.DynamicForm.getOperatorIndex(),
             validOps = isc.getKeys(opIndex),
             result = { operator: "and", criteria: [] },
@@ -11597,7 +11593,14 @@
 
         return result;
     },
-
+
+    isValidLogicType: function() {
+      var type = this.getType();
+      return (isc.SimpleType.inheritsFrom(type, "integer") ||
+          isc.SimpleType.inheritsFrom(type, "float") ||
+          isc.SimpleType.inheritsFrom(type, "date")
+      );
+    },
     
     useWildCardsByDefault: true,
     _betweenInclusiveEndCrit: "ZZZZZZZZZZ",

[Isomorphic]

Just for our reference, what new logical operators are you adding? We didn't know there was still innovation in this area ;)

Aside from of course NAND, nor, XOR, etc.

[martintaal]

:-), no new logic operators, just wanted to make the current set of symbols customizable.

My idea was I can make just the between operator configurable. But that's not such a generic solution. A more generic solution would make all operator symbols configurable, for example to use something different for inSet also.

But if I would need to follow the generic approach then that is a bit too much code (as there are several places with hardcoded symbols in the parseValueExpression/buildValueExpression code), which introduces risk of errors from my side. So I rather do something more generic or not have the change at all.

The last change I propose is for something slightly different, I use text items for numeric fields/filtering, this because javascript/json numbers are not precise enough (loose precision when being de-serialized). So I send all the number as clear text to the server to be converted there to a BigDecimal.
But or/and logic is not supported on text items so therefore the change I propose.

gr. Martin

[Isomorphic]

It's not clear what your patch accomplishes - are you trying to create yourself an override point? If so, go ahead and override parseValueExpressions(), either way you'd be overriding an undocumented API and it's something to track when upgrading.

[martintaal]

In this case I would need to copy the complete parseValueExpressions in the subclass, just to set isValidLogicType to true (to allow or/and also for text fields). So therefore my request to allow another way to indicate that and/or are allowed in the value expression.

gr. Martin