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.
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 
. 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.
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.
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.
So this request basically boils down to Server Side Rendering for PHP? 
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.
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 
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!!!”
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.
Oh ok. Thanks for the final confirmation!
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?
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!)
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.
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.
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.
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.
That’s fine - particularly as you’ve voted.
That part was a joke Tom 
The problem is that everybody in this topic was resolving a different problem I think. Including myself.
I think this is a very bad implementation option for CMS. I can’t say for sure, because I don’t have comparative tests, but even representing the load created in theory, I can predict quite accurately that in my case this will create an excessive load on the client side, when will be necessary to analyze all Conditional Regions, which will also have to be repeated (in total, there may be about a thousand Conditional Regions). I worked a lot with Conditional Regions, but not in this variant.
Plus, this solution is extremely not flexible. If I change elements, remove elements, or add new ones, I will have to make these changes to the created massive matrix on the page.
It did look promising but I couldn’t get this to work.
I’m afraid this thread has gone off on so many tangents that it might deter people from voting (for what would be such a useful feature). Perhaps @Teodor could give it a boost by merging it with this one. Or perhaps that would make the thread even more confusing.
(I’m not sure how I managed to overlook/forget about this one. I voted for it at the time.)
