Parse AC expressions stored in backend as strings

Feature Request
#14

I think you are talking about something different. OR maybe I am. :laughing:
@TomD correct me if I am wrong here.

Here’s another summary of what is needed here:
Consider this normal Wappler expression which will parse the dynamic value part and assign some value to varDynamic variable.

<dmx-value id="varDynamic" dmx-bind:value="sc1.query1.id == 4 ? 'yes' : 'no'">

Now, consider a table in DB which has a field dynamic_expression and the value in there is sc1.query1.id == 4 ? 'yes' : 'no'
Using a SA, I can fetch this data via simple query.
Next, in the client side, once I get this data via SC, I would like to bind it in the following manner:

<dmx-value id="varDynamic" dmx-bind:value="sc2.query1.dynamic_expression">

Here, the output expected is that App Connect parses this binding to fetch the value sc1.query1.id == 4 ? 'yes' : 'no', and then does another parsing to evaluate and return yes or no.
So, when value of the variable is checked, it would say yes or no instead of the DB value.

The link shared in the original post, shows a client-side component which is capable of doing the second parsing.

Similarly, if I have complete HTML in there, say the dynamic_expression field has this value:
<dmx-value id="varDynamic" dmx-bind:value="sc2.query1.dynamic_expression">
Then, when I bind this on the page, it should get parsed into a regular variable on the page as any other variable.

Things however get complicated when this dynamic_expression also needs to have string containing binding expressions {{ }} stored as well.
Some of it is possible to do via server side data & server side rendering in NodeJS, but the primary requirement here is from PHP perspective.

#15

I think we are talking about different functionality. I read more carefully how Tom has implemented it now, and realized that there is nothing to do with App Connect at all for this, and there is also no need to do any other interpreter.

Only one thing is required - before loading the page, make a request to the database and load the stored code from it. The principle is the same as security works now - first the registered user is checked (it doesn’t matter PHP or NodeJS), after the check the page is loaded. If you add preloading of the code, then when the page loads, all the elements will work correctly, as if they were on the page initially and there are no changes to be made in App Connect.

You are mistaken in this. There is no point in creating an analog of a Wappler or a CMS with the help of a Wappler that would compete with existing advanced CMS (Wordpress, Joomla, etc.). But it is possible to create a CMS that is extremely simple, with an intuitive interface for the user who does not know anything about the web at all and does not even understand what the words html and css mean. And for this, the Wappler fits very well.

For example, in my task, it is necessary to build a CMS so that the user can create a web version of his magazine, which he publishes. To do this, I need to design about 30 elements in advance, from which the user can construct any design of the pages of his magazine. He will select these elements from the list in the interface and simply add content to them with the possibility of changing some additional settings for which he does not need knowledge of html or js.

#16

This is server side data & rendering you are talking about which is already supported in NodeJS.
So this part you can already do in Wappler NodeJS project.
The server side SA is not restricted to just checking if user is logged in or not.

From my understanding, like I wrote to Tom earlier, if you can build the UI to do this, you already have a UI to output it.

#17

Guys. This is the original request.

If this request is just for App Connect this is literally not possible without using eval() or the global window object. And none of these options are a good practice.

You can put it anyway you want. Call it binding, dynamic variable or Wappler black magic. It’s all JS beneath.

There is a workaround by using object square bracket notation for that.

Maybe this is just an XY problem and Tom really needs to explain in detail what his problem is so we can look for the right solution.

Unless this part is the real problem:

It’s all very confusing to me.

If it’s just this and I want to pass from the backend to frontend an App Connect expression to be parsed on the frontend it’s doable. I have some core files modified for this.

All in all I am rooting for this to be an XY problem.

#18

This is indeed what I want. I gave two examples above of what I might want to store in a database and then want to be parsed by App Connect:

{{field_1}}
or perhaps including HTML and literal text:
image

#19

Then it’s doable. I have done that for validation messages that are generated in the backend but translated in the frontend.

You can see in my post that I am passing an expression. I modified some core files to get it working, but a more standard approach would be desirable.

#20

I’ll probably stick to using PHP and non-Wappler database connection and queries, rather than modify core files (but neither is a great solution). Perhaps you should vote for this request :slightly_smiling_face:. I thought it was fairly clear, but it seems nobody understood it.

Perhaps an extract from your post would be better:

Is it possible to preapply an AC formatter in the SC return value so it’s parsed on the client?
…
This is being treated as a text and I believe it will always be unless there is some kind of magic formatting that can let AC know that this is not actually a text and should be evaluated.

#21

I have not previously used the server-side rendering capabilities in NodeJS, but having checked the documentation now, I believe that this can really help in implementing the required functionality. Only you will have to render not individual sections of the text, as in the documentation examples, but most of the page. I can’t say for sure yet whether this will work, because i need to try it.

This is not entirely true. If you know in advance where the page elements are located, then you can immediately build an interface for data output. But in the case of a CMS, the situation is different, you do not know where certain elements will be located on the page, because the user constructs the page. You only have the option to save the items that the user has selected in the desired order in the database. In this situation, there is no ready-made interface for displaying the constructed page. There is only the code of this page stored in the database. And your task is to output this code to the page so that all dynamic bindings work on it.

Tom, I think I understand you well, and our needs coincide. I will try to implement server-side rendering in NodeJS for my tasks and, if the result is positive, I will write to you about the results.

#22

I you have the 30 elements, you know what HTML will be generated already. CR is what I use for such an implementation.
But this is not the point of this request. So probably something to solve in some other topic.

#23

So this request basically boils down to Server Side Rendering for PHP? :sweat_smile:

#24

Sorry - I should have mentioned that I thought you understood me (and reassured me to some extent that I wasn’t in fact talking nonsense).

I would be interested to hear of your progress with NodeJS. It’s mainly the hosting issues (and time) that keep me from exploring NodeJS with Wappler, but it’s also concern that I won’t know how to do things like this - things which I can do with PHP.

#25

Tom reassured a few posts ago that he wanted to parse strings with AC expression format coming from the backend on the front end.

And now he can fix this with php server-side?

I think nobody knows what this is about. Not even Tom :joy:

XY problem in all its glory.

24 posts for a feature request and I genuinely don’t know what I am voting for. I suggest this thread to be closed until someone figures out what we are actually requesting.

-“This is madness.”
-“This. Is. Wappler!!!”

#26

Not really. It boils down to a wish to avoid exactly this - to avoid having to create separate/duplicate database connections and queries just to provide a string which Wappler will evaluate. @JonL perhaps put it more clearly:

Is it possible to preapply an AC formatter in the SC return value so it’s parsed on the client?
…
This is being treated as a text and I believe it will always be unless there is some kind of magic formatting that can let AC know that this is not actually a text and should be evaluated.

1 Like
#27

Oh ok. Thanks for the final confirmation!

#28

In this case, we are talking about the same result, but about a different implementation. Although it doesn’t matter to me how the functionality will be implemented, if in the end I can display the saved code from the database, in which all dynamic bindings will work.

Would you mind explaining that? What do you mean by CR?

#29

I’ve made the point about alreay being able to use PHP repeatedly, in this and several other threads, going back to the thread where I first raised the issue (in March 2019!)

#30

Sorry, CR = Condtional Regions.
If I have fixed 30 types of components, only the ordering is dynamic, I just create those 30 elements on the page and put a CR on each of them.
Then, using a repeat on that, only one of the items will show up in the UI for each row.
I have done this with 10 element types. Works great. Not sure about 30 though.
Having CR means limited items are renedered and limited work for AppConnect to do… so no performance issues.

#31

In this case, doesn’t this link you shared, work for you: Button on mouse click inside of Server Connect Variable ?
It looks like it treats a string as Wappler binding and parses it.

What you are after is resolution on client side, so it will have to be some formatter or a component like above.

#32

I’ve taken the liberty to change the topic name to something more appropriate/descriptive. Feel free to revert if you think it doesn’t convey the idea.

#33

I know exactly what I want. To create a UI where a user can make a selection of fields, and format them as they want, and for the result to be stored as a template, in a database, and then reused when required on the front end.

Here is an example from a feature in a desktop application I developed about 10 years ago. The user clicks on a list of fields, applies formatting, as in a word processor, and creates a template for future use. They may want to create many such templates; each one is a database record. From this template they can generate different catalogues - different formatting, with/without images, with different currencies etc.

This is obviously a specific application, but I’m sure there are many common uses/needs for such things.

image
image577×586 26.1 KB