Parse AC expressions stored in backend as strings

Feature Request
#3

I probably didn’t explain this very well.

Here’s an example: I’ve developed some software for a number of years (not using any web technology) where users need to create layouts/templates where they can select whatever fields they want and choose the fonts, format, styling, as well as currency and language etc. These templates are used to create lists and catalogues etc. In this situation it makes sense to store both the data and the templates in a database. I’m interested in a corresponding solution in Wappler.

I can do exactly what I want by inserting the template string using PHP - so it doesn’t make any difference to the client-side performance. I don’t see why it should necessarily make any difference performance-wise anyway, as you’re suggesting, even if it were possible to do this using Wappler/App Connect. The list of bindings will be evaluated in either case - whether they are hard-coded in the page (or at least by the time the page arrives on the client) or not. I suppose there would be an extra step as the string is retrieved from the database but after that, I wouldn’t have thought there would be much difference.

As I mentioned in another thread, it might be a little like using dmx-html to tell Wappler to parse embedded HTML tags in the data. I haven’t noticed any performance issue when using this attribute. I have no idea if this would be very difficult to implement or perhaps something that would be quite simple - and can perhaps already be done.

#4

Tell me if I’m on a different wavelength.

I want a variable’s actual name to be dynamic. So I can dynamically select a field within a record rather than a record within a table.

#5

I think we’re on the same wavelength - or at least a similar one. I think we both want to be able to control dynamically the value of a binding (for example). Eg in a repeat you might include {{some_field}}, but you want the value ‘some_field’ to be dynamic. There is no problem doing this currently - except Wappler won’t evaluate the code if it’s created dynamically.

This is what I would like too. I would generally like to have the option of any string (consisting of variables, bindings, static text etc) to be evaluated in the same way whether it’s hard-coded or generated dynamically.

#6

I agree that an additional evaluation of the code will create an additional load and this will negatively affect the performance of the application. It does not matter whether this analysis is carried out using new App Connect components or it will be custom solutions. The main question is how to make it more effective?

Imagine that you are creating a CMS functionality in your project and your user creates such an element with the help of your editor:

<img class="cse_mess_avatarContact" dmx-bind:src="avatar != 0 ? (unic_code ? 'img_avatar/'+unic_code : null) : null" dmx-show="(avatar != 0)">

You save this element as plain text in the database (using a field in the varchar or text format), so that you can then render it in the right place when someone accesses the page that the user created.

As you can see, this simple element contains a lot of dynamic elements, so if you use the usual inner html, this element will not work. Which solution in this case do you consider effective for implementation? The request for this function is exactly about this.

For some reason, I have a strong feeling that you are talking about something else, but I’m not sure what exactly. :slightly_smiling_face:

#7

This is server side rendering that we are taking about here I think. But the final evaluation still have to happen on client side.
Which will impact client side performance as much as adding too many formatters on a page does.

I might be wrong because I am a bit confused here to be honest. :sweat_smile:

I get this idea, but this does not answer the performance issue question.

If I look at this from a bigger perspective, such a requirement means that the app being built is for advanced users who know html and maybe even Wappler. Similar to other CMSs which give great flexibility, if you know what you are doing, and doing it in their defined syntax.
And I don’t think Wappler is a good fit for such an application yet. But maybe few years down the road.

#8

If this is what you actually want to do:

var a = 'string1'
var b = 'string2'
var c = 'a' OR 'b' //pseudo
var d = c
console.log(d)
//outputs ‘string1' or 'string2' depending on the value of c

This is not supported by javascript out of the box. There are a few workarounds to make it work but I highly doubt the team wants to go there due to the implications(security being one of them).

So you will get:

var a = 'string1'
var b = 'string2'
var c = 'a' OR 'b' //pseudo
var d = c
console.log(d)
//outputs ‘a' or 'b' depending on the value of c

Additionally, know that this you can do:

var obj = {}
obj.a = 'string1'
obj.b = 'string2'
var c = 'a' OR 'b' //pseudo
var d = c
console.log(obj[d])
//outputs ‘string1' or 'string2' depending on the value of c

In your example:

var html = {};
html.div1 = '<div>string1</div>'
html.div2 = '<div>string2</div>'
var field_4 = 'div'
var field_5 = '1' OR '2' //pseudo
console.log(html[field_4+field_5]);
//outputs '<div>string1</div>' OR '<div>string2</div>' depending on the value of field_5

So you could try storing what you want returned in an object.

Can variables be dynamic?
#9

If I use PHP, of course this part is done server-side and App Connect will evaluate the string as usual (it won’t make any difference to App Connect how the code was generated). However, using PHP to do this - to incorporate the template string into the code - means setting up parallel database connections and queries etc, ie not being able to use Wappler for this.

I still don’t understand your point about performance. If I have {{some_field}} in a repeat, this evaluates pretty quickly. Performance is fine, even if I have a series of such expressions, perhaps including HTML (I often do). If your concern is related to this, that’s a different matter. I can create this string using a database query - to make the content of the repeat entirely dynamic - but, as far as I can see, only using PHP (not with Wappler). Again, performance is not the issue - the additional database query required is hardly significant.

If the string to be evaluated is inserted using Wappler, from a database query, it’s treated as literal text. My request is that there is an option to treat it as a string to be evaluated, as in the cases in the previous paragraph. I don’t know why that would have performance implications, but perhaps it would - or perhaps it’s simply not possible or feasible. I think what I’m suggesting is something similar to an eval() function (which I realise is not popular, but can be very useful in some circumstances).

#10

I don’t think this is necessarily true. It’s up to the developer to create an interface where the user can simply select the fields they want from a list and apply formatting etc. - more or less as they would using a word processor. This can then be used to create the string stored in the database, which in turn will be used as a template in the final page. The user need have no knowldege of html, css or Wappler.

#11

You probably haven’t had a very complex page with multiple repeats, multiple nested repeats & multiple expressions.
This is something that I have experienced many times. And to solution has been to change my logic to reduce client-side processing to a minimum.

The interface you are talking about would pretty much work as the real thing as well. So if you can create that interface, the output is pretty much created too.

I do not have much experience building or using this sort of application. So theres a good chance I am missing some other point about this whole thing.
But from what I do understand, this dynamic data binding and parsing thing does not seem like anything of great value yet.

#12

I still don’t see how this relevant. If what I’m suggesting would have a very signficant impact on such situations, to the extent that it wouldn’t be useable, then that would be relevant - but I don’t know if it would have such an impact.

Supposing there was no option to evaluate HTML embedded within data - ie there was no dmx-html attribute. I would post a feature request asking for this, and you might point out that this might add some overhead to the client-side processing and therefore shouldn’t be implemented. (I don’t know whether or not dmx-html adds significant overhead - but it’s up to me to use features in a way to maintain acceptable performance).

Yes, but the whole point is to store this ‘template’, and in such a way that it can be used dynamically in a page.

I would have thought there could be many applications. I use such functionality a great deal (not in Wappler or web-based software). @Mr.Rubi perhaps gave a better examples in relation to developing a CRM application.

#13

Again, since JS doesn’t support this for a good reason and App Connect is a JS framework I don’t know what you guys are discussing for :slight_smile:

If you need this use objects with bracket notation as a workaround.

#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.