More Clarity in Layout of The Data Formats Expression Editor for Creating Complex Expressions

[Antony]

I’ve been using Wappler for 5 months, and I have never been able to relate to how the menus are used to create a complex expression… which has lead me to edit expressions in code more often than I would like!

Here is a simple example I have struggled with:

(var1.value==0) && (var2.value==1)

After seeking help on how to create this, the format in the Data Format window is this:

The nesting in this layout and the series of clicks needed to create it just doesn’t make sense to me. Why do I go back and click on var1 in order to create an expression only involving var2?

This implies to me that the bracketing is:

(var1.value== 0)  (var1.value && (var2.value==1))

Which doesn’t really mean anything.

I think the issue is that this window does not show a root position which the user can come back to in order to create the second expression. If the window was laid out like this to create my example:

Expression:
   var1.value
      -> ==
        -> 0
&&
   var2.value
      -> ==
        -> 1

Then the layout and the series of clicks required would exactly match the structure of the desired result:

(var1.value==0) && (var2.value==1)

I think this is a similar issue to the one that came up with the layout of the Server Action window, where you added the “Server Actions” root location and then everything made sense.

It would be even more amazing if the construction of an expression happened horizontally rather than vertically, since most of us are used to programming of expressions being shown that way.

So the display would look like this when you add an operator

Expression:
   var1.value [OPERATOR] [VALUE]

Then you click on [OPERATOR] AND [VALUE] (Which would be icons of course) to set the operation and value and the display then looks like this:

Expression:
   var1.value ==  1

(Even if you left the construction of the expression to be vertical, it would be great if this is what the display would look like if you collapsed the whole var1.value expression.)

I hope this is helpful feedback… I know you want to move people away from editing the code and creating mistakes, so I feel it is important for you to know what has really held me back from using the menu system.

I’d love to hear your feedback @George, @Teodor, and @patrick!

Best wishes,
Antony.

[George]

The visual expression you generated is indeed correct, and it generates the correct expression.
Each new level implies new brackets:

results in:

((var1.value == 0) && (var1.value == 22))

So the brackets are correct

[UKRiggers]

Hi @George, I can see where @Antony is coming from.

The two green areas marked indicate that the functions “==” and “&&” are on the same level, but they are not in reality as your red areas indicate.

[Antony]

But George, my point is that your second red box (which I will assume refers to var2) is nested under var1.value, and you need to click on var1.value in order to create it… yet is has nothing to do with var1… it is the second part of the complete expression.

The terms (var1.value==0) and (var2.value==22) are at the same level of the expression’s hiearchy, yet in this display, (var2.value==22) is shown beneath (var1.value==0)

All I am saying is that for me, the way this is structured doesn’t make any logical sense and has caused me to have to write expressions in code, which I know you want to discourage!

It just seems soooo much more logical to introduce an expression_root…

[George]

Actually what we are trying to mimic here is an binary expression tree. There the root is actually the operator and then you have left and right values.

Expression Tree - GeeksforGeeks

However as our starting point is always a variable, we made a more logical variable tree expression, hence the first root being a variable. And in my opinion a bit more readable tree that the pure binary expression tree.

[Antony]

Well George, all I can tell you is that an expression tree starting with a variable makes absolutely no sense to me and has caused me to move to writing more code than I want to have to do…

I’d love to hear other user’s opinions!

[George]

I agree that for building logical expressions the current data formatter UI might not be perfect. It was originally designed for formatting data with the supplied formatters and there the starting point is always a variable.

We are researching for more better UX specifically dedicated for logical expressions.

Some nice examples are listed here:

Intuitive interface for Composing Boolean Logic?

But you can always contribute with your own ideas and mockup

[Antony]

Yes, that makes sense now… the current interface is great for formatters but not so clear for expressions.

Hopefully my idea of an expression root may be able to contribute to an environment which can combine the two.

The place where expression building is really nice in Wappler is the Conditions tab of a Database Query Server Action step…

Thanks for hearing my perspectives George!

[aschoijett]

Hi,
I strongly agree with Anthony. IMO, the formatter functionality is not intuitive, not well documented, and not well organized. I made a few suggestions for improvements in this posting: Observations and Proposals for the Wappler UI but have not received any response yet.

One of the suggestions was to use a UI similar to the one used to create conditions in a server action database query. The UI used there is much better than the one used by the formatter and the Wappler team is already maintaining that code. I would still polish it a bit further, making the fields for the operands larger, and organizing the operators differently (e.g., as proposed in the posting above) but the basics for a better UI are already there.

Hope this helps,

Alex