This seems to be a bug related to how Wappler handles special characters in attribute values — it should preserve the raw content for templating syntax like EJS.
Please let me know if you need a clean test file to replicate.
This has been so since first version I think.
In some cases, the editor does handle the EJS expression correctly, and does not change it.
But in most cases, it does not.
This happened, a lot! to me, I'd have a group of rendered values that would need to be reinserted for dmx-onclick action again, and again
However, I did notice, that values don't change,as long as component's aren't altered, e.g. if you have onclick event and open app connect value binding window,or binding additional values via monaco editor. I could swear the ssr values were affected less if wappler didn't have to touch them again!
Actually, I haven't tried whitespace slurping tag inside the attribute binding, but If i remember correctly, design view simply doesn't even recognise them, as I used them for dynamic javascripts,etc. <%-_('script',locals)%>, maybe worth a try and quotations won't affect them?
For future reference, can confirm, binding SSR values with whitespace slurping tag <%-_('user.email',locals)%> inside of the quotations dmx-bs-tooltip="'<%-_('user.email',locals)%>', prevents wappler converting < and > to less than, or greater than conditional operators. However, are no longer visually dynamically bindable(via server side/app connect popup manager/window).
I haven’t seen any updates to ssr or anything related to it, since ive started using it. Given the nature of the issue, unfortunately I wouldn’t wait for the fix just now, and proceed to apply the ssr normal way, and refrain from editing elements in properly panel, as this is what seems to be causing this behaviour. No matter the structure of the syntax. It would be great if we were able to enclose them is special characters that would prevent such behaviour though!
