AC formatter in SC validation message?

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?

image

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)

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.

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.

image

image

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.

@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?

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.

1 Like

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.