The new visual picker doesn’t make much sense except for visuals. It does not even allow you to make changes manually in server action. Detection of errors is very difficult in this way. I think visual picker is not a good idea.
Hello Serhat,
Thanks for the feedback.
We started integrating the new visual builder because of many reasons, mainly people trying to add code manually in the expressions picker, without using the UI. In most of the cases there were quite serious issues (as people were trying to add all kind of weird stuff) with wrong expressions code generated and broken pages.
So now it is only allowed to generate dynamic expressions using the UI, making it bulletproof for such cases. Also with the new expressions builder there is no need to know when to enter quotes " ", single quotes ' ' , backticks ``, curly brackets {{ }} etc.
For static text you just enter: text and for dynamic expressions you just select them from the data picker and all the quotes are added automatically in the code where they belong.
So in UI it all looks the same and not until now, with the old data picker you could see many different expressions using different syntax. Example:
dmx-bind-atribute="'static' + dynamic"
or
dmx-bind-atribute="static{{dynamic}}"
or
dmx-bind-atribute="dynamic.formatter(`something_here`)"
really confusing for the users.
2 Likes
I actually like the visual picker better, but it’s not fully developed so it doesn’t work at its best yet. For instance, I would expect to be able to click on a colored box to change it, or to add a operation to it or something. Instead you have to click on the magic wand first. The box that then appears isn’t as visually user friendly as I personally like. For instance the operators being code (==), instead of words (Equal to).
I will try to add more feedback when I see something.
Well that is exactly what we are trying to avoid. There are TONS (really) of error reports in our Sentry reporting tool, which show exactly how people are trying to edit the dynamic expressions and entering really weird stuff in there, leading to issues on their pages, hard to debug problems, false bug reports in the community etc. and all of this because they don't use the UI 
If you are using the magic wand, i.e. the Data Formatter the code generated will always be correct.
That's something we can change probably if its really not clear.
@George will check it.
1 Like
I meant clicking the colored box and then the window of the magic wand appearing. I didn’t mean changing any code. Just to be sure we are talking about the same thing.
2 Likes
Ah, so you mean directly show the formatting options on click/right click?
That’s a nice suggestion 
1 Like
Yes indeed. Visually only showing the options to change for that specific colored box
1 Like
@Teodor, I am a bit confused by this statement. Are you saying it will be impossible to edit dynamic expressions in the code after version 2.7.2 or after version 3.0?
No Antony,
I am referring to the dialogs in the UI - where you pick the dynamic expressions and bindings and format them.
You can still edit any of the code you placed on the page in Code view.
1 Like
Is there a page showing what the different colours mean in the new visual data picker? I’ve searched but can’t find one.
I may be missing the purpose or advantages of the new visual picker, but so far I agree with @s.alpaslan. I appreciate the issues regarding correct syntax and valid expressions etc. This problem has been raised many times - in some cases the UI makes the required syntax very clear; in other cases, the UI gives no indication at all, and it's a matter of trial and error. Improvements and more consistency in the UI could help a lot.
I appreciate we can still edit expressions in code view. I always use split view and it's often quicker and more convenient to edit the code. However, I very rarely edit the code directly on the Server Connect side. It would be a pity if this was the only method of entering expressions manually.
Currently it's very easy to understand an expression like this, and to edit it if necessary:
.. but it's not easy to understand this:
.. and you have to click 7 or 8 time to make a single change, just using the UI. There are some expressions which would take much longer to enter using the UI.
But it seems it's still possible to remove this:
.. and replace it with this:
I apprecate this is not very useful in itself, but if you're debugging an expression and testing a number of variations, only being able to use the UI would be extremely frustrating. I tried this yesterday and decided the best method was to have a text editor open and to copy/paste expressions between that and Wappler
Currently it's possible to switch off the new feature. It would great if it were possible to keep both options, but I daresay it wouldn't be feasible.
1 Like
Tom, you can view the whole expression when you hover the tag.
Clicking a couple more times will make your code correct, which in most cases will save users from entering wrong expressions by hand and then reporting a false bug
May not be making much sense for you, but from what we see in Sentry and in the community that's quite a common case.
1 Like
Thanks Teodor. I realise I can see the whole expression by hovering over the tag. However, in itself, this is hardly an improvement: at the moment I can see the same expression without the need to hover.
Frequently, without the new visual changes, long expressions are only partly visible anyway. Often in such cases, the simplest way to view or edit such expression is to copy/paste them into a text editor. It’s not ideal but it’s an option. As far as I can see this won’t be an option any more. I think I’ll make a feature request about this.
@TomD - you’ve still got code view. I spend 95% of my time using split view so I can see exactly what’s happening and tweak as needed.
I always use split view for the same reasons as you. As you say, the new features won't change this option.
However, how much of the time do you spend using code view when editing server actions? I mean viewing the PHP files and tweaking the code there? I rarely do.
Yep, I know what you mean. From a UX perspective, double-clicking on a visual tag to turn it into the full, editable code as it was before would be the best solution. Then, when you come out of it (focus away, hit return, whatever) it goes back to the visual tag. How does that sound?
3 Likes
One thing you can be sure of is that it will be impossible to make everyone happy. I would much prefer '==' to 'Equal to'; it's more concise, more familiar and (IMO) just as clear. With other operators - such as 'Greater than or equal to', expressions could become more cluttered and verbose. I wonder if words for operators such 'modulus' will be clearer or help anybody.
I think this would be a much better solution and what I assumed would happen when I first saw these tags. I tried a few right and left clicks to confirrm I wasn't missing something.
My impression is that the intention is to prevent such options being possible. A case of throwing the baby out with the bathwater.
1 Like
Put it as a feature request?
That's only in the UI, not in the code.
Same as you have these operators in the database query builder in the conditions tab.