dot:InlineScript and resource binding & migrating WebForms JS server tags

🌎 Discussion in English
1

Hi all,

Actually having two questions that are closely related:

  1. Is it possible to bind a resource in markup file (.dothtml / .dotcontrol) inside a dot:InlineScript control? It seems not. If indeed not possible, how to work around this? Reverting to simple <script> HTML tags is bad, complicating things a lot.

This, as a test, works:

image

But this fails:

image

with browser error/log page:

image
image1098×338 20.7 KB


  1. The broader question: how to properly migrate blocks of JS that are filled with server tags feeding control client ids into the JS and avoid hard coding ids?

Example of such a WebForms JS block:

image
image875×342 48 KB

Of course we want to change the legacy JS as little as possible as to avoid cost impacts on the migration efforts. Restructuring it is out of the question - too costly, we have many situations like this example that implement various custom front-end functional/UI-UX extensions to the WebForms controls.

2

Found this resource: javascript - Value binding in <script>-tag not working - Stack Overflow where it is suggested a client-side way of binding the view model properties to the JS code.

But if I go with this approach, I am facing my previous forum question, of course: Visual Studio 2022 suggestions for dotvvm front-end object and its members - #2 by MarianV

3

(1) Yes, you most likely want to use the value from the view model (you can use dotvvm.state.MyProperty to avoid knockout observables). If you’d really need to place constants into JS string, you can create the script in the view model and use

Context.ResourceManager.AddInlineScript($"alert('Test: ' + {JsonConvert.ToString(Something)})");

The resource binding inside the <script> tag does not escape for use in JavaScript, which may lead to XSS bugs if the inserted string can be controlled by the user.

(2) I don’t know, maybe @tomasherceg has some guidance. If it’s a page where the ids are the same, I’d probably just inline the constant IDs for the transition (copy the generated JS from the browser instead from the aspx file)

4

(1) Interesting and I will keep this variant in mind. Unfortunately, it is an anti-pattern in our project (JS code must stay in the markup file).
And yes, I try to keep as far away as possible from wrapping the migrated JS code into simple <script> blocks.

(2) I really miss the comfort and productivity of what WebForms permitted (see the “trick” in earlier post) by using in front-end JS/jquery selectors, the client ids of the controls (no hardcoding and if changes or refactoring happened - the references would fail with red underline in the editor - which is evidently a big plus in time for the maintenance aspect of the project)

I think this suggestion would limit me to “hard code” the client IDs.
@tomasherceg What do you think?