AC formatter in SC validation message?

[JonL]

I am recategorizing this as a bug as in the very nature of Wappler any data sent from SC to AC should be parsable. Currently validation messages sent from SC to AC are not parsable and therefore are fixed. I worked around this by parsing the message directly in dmxValidator.js but this is not the standard approach

I need to send an error message from SC to AC.
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.

Why? I need to translate the error message via i18next(without integrating again i18next with SC)

[JonL]

I have been digging through the php and js files for the validation and also the SC parser and I believe there is no way of doing this at the moment.

The SC parser will intercept any attempt of sending a token to AC as they both share the same format of double curly brackets. And the js validation is hard coded so I cannot set a formatter.

But I need those messages translated.

Can you implement a new token that will be parsed(but not evaluated in SC) and sent to AC for evaluation via the dmxValidator.js? Or integrate further the validation logic in AC so we can set formatters on the messages that are sent by SC.

The other option for me would be to reimplement i18next library for PHP which seems overkill given that I already have it in the frontend.

[JonL]

So I finally gave up on trying to find a workaround that doesn’t imply modifying core files.

I added a “fix” so that the dmxValidator.js would parse the expression:

s.textContent = t.startsWith("'") ? dmx.parse(t) : t

dmx.validate.setBootstrap4Message = function (e, t) {
        if (!e.hasAttribute("data-msg-custom") && (e.getAttribute("name") || e.getAttribute("id"))) {
            var u = e.type.toLowerCase(),
                a = "dmxValidatorError" + (e.form ? e.form.getAttribute("id") : "") + (e.getAttribute("name") || e.getAttribute("id")),
                s = document.getElementById(a);
            s || ((s = document.createElement("div")).id = a, s.className = "invalid-feedback", e.parentElement.appendChild(s)), e.hasAttribute("medium-editor-textarea-id") &&
            (e = document.getElementById(e.getAttribute("medium-editor-textarea-id"))), "hidden" != u && "g-recaptcha-response" != e.name && 
            (t ? (e.classList.remove("is-valid"), e.classList.add("is-invalid")) : (e.classList.remove("is-invalid"), e.classList.add("is-valid"))), s.textContent = dmx.parse(t)
        }
    }

Finally I made sure that the string returned as the validation message was parsable.

Resulting in:

In summary:

Can we get validations messages parsed correctly in SC so they can be formatted in AC?

Any string sent from SC is “formattable” in AC as a data binding but SC validation to AC is hardcoded so I can’t apply a formatter.

I would rather avoid having to deviate from standard by patching core files.

[JonL]

@Teodor @George I have the feeling that recategorized topics from whatever to “bugs” isn’t picked by whatever tool you are using to handled tickets, right?

[Teodor]

Hello Jon,
we are aware of this topic, it’s currently not our top priority. It’s how the validator was created to work.

@patrick will check how could this be improved.

[JonL]

@Teodor

it’s currently not our top priority

Yeah I do understand that. It’s not even a priority to me either as I have a working ugly hack.

I inferred you have the bugs category interfaced with some ticketing tool(because that’s what I would do) but I didn’t know if re-categorized topics would be picked up.

[JonL]

@Teodor did this by any chance ascend a few steps in the priority? Can I send beer or NFTs to bribe someone? Or even better an NFT of a beer gif!

[patrick]

Instead of editing the dmxValidator.js you could just update the html attribute by adding dmx-bind: in from of it, it should then parse it for you dmx-bind:data-msg-custom="'val-field-required'.t()".

[JonL]

Isn’t that for browser validation?
My problem is for server validation.

[patrick]

In the file lib/validator/index.js line 25.

const options = item.rules[rule];

change it to:

const options = app.parse(item.rules[rule]);

Then in the message set an expression like {{ 'val-field-required'.t() }}.

If it works then I will update the code for the next update.

[JonL]

I haven’t tried but I’m assuming that will parse the expression on the server which is actually not a bad thing and I believe it will come handy. I believe others have asked to be able to add server bindings in the validator message. I would go for it in any case.

Still my issue is that the .t() formatter is an AC formatter. It’s not available on SC as I do all my i18n logic on the front end.

The idea would be able to send a "{{binding}}" string to the frontend so it’s parsed there by AC.

To enable both features(parsing validation messages in SC and sending a parseable string to AC) maybe you could add a new moustache notation for the latter? i.e.{%binding%} or whatever feels right for you guys.