Container Id must be a fixed name for external component - How To Do?
Question
Application Type
Reactive

I need to use an external component (windy.com) to show a map on a screen. A requirement from this component is that the div (container) that will host the map has the id "windy". Nothing else then that, just "windy". 

But when I name the container OutSystems will always put a prefix to it, as is completely normal for OutSystems to do. But in this particular case I don't want that. Is there any way to set a non-mutable (by OutSystems) id for a container?

And no, there is no way around this. 

Greetings,

Vincent

Solution

Thanks for the replies, I thought there was no native way when you make use of blocks. I did however find another way via Javascript that I find a bit more elegant then creating the div via Javascript as @Dorine Boudry mentioned. You can simply rename a div with the following statement: document.getElementById('oldName').id = 'newName';

So I just created this javascript action then I call in the onReady event handler and this works perfectly:

Yes ok,

So my thinking was I might be reluctant to do this, because I can't be entirely sure that there is not some platform-generated code that is relying on the id.  So in general, I would be hesitant to change an id that the platform has given to an element.

I made a little demo app to test it out, and turns out that both renaming and adding a child could get into trouble, depending on what else is going on in your screen.  For example, in a scenario where they are part of a container that sometimes has Visible set to false, both the rename and the added child are gone after making them visible again.

See attached demo.

Thinking of it, this makes sense to me in this way : OS has a representation of the screen in react code/variables, and builds the DOM from there, so the dom is not the source but a result of a refresh from the internal state of the screen.  Renaming elements in the dom, or adding child divs to the dom, are not represented in this internal state, and get wiped when OS refreshes the dom.  Something like that, not sure I'm using the right words.

So, conclusion is, both renaming or adding child divs might get lost, you could try doing the rename in the onRender instead of the OnReady.  See attached demo, in that case they are the correct name  after making visible again.

Dorine

It is true to you could get run into collisions, that is something to keep in mind. But I'm sure that as long I put into the documentation that you should not name a container "windy" in the same screen as where you will host this web block that everything will work out find. It is not something that I will worry about especially since I can't do anything about it. It's a requirement from a 3rd party component that our business wants to use. We will deal with the accompanying rules.

And wouldn't a change to the Dom result in an OnRender event and therefore run into a continues loop with your suggestion about event handling placement?

Nope,

changing the dom doesn't trigger an OS OnRender event as far as I can tell.  See attached demo.

so if you don't have collision and dont sometimes make it invisible, all will probably be ok with an OnReady.

Hi Vincent,

I am not sure i understand your problem correctly but Just name the container "windy" it will generate div with id windy.

Please find below images



Hi,

@Devendra Singh Baghel : that is only true for divs that are not a part of a list or on a webblock.

@Vincent Koning : assuming that you are putting your windy map in a reusable webblock, I would try by manually creating a div with the desired properties in the onReady of the webblock.

so, draw a 'parent' container in your design where you want the map, and then add your windy div inside it.  

I don't know anything about the windy api, so I'm not sure if this will work for you.

Dorine

@Dorine Boudry  Sorry I misunderstood the question.

Best regards

Devendra

Solution

Thanks for the replies, I thought there was no native way when you make use of blocks. I did however find another way via Javascript that I find a bit more elegant then creating the div via Javascript as @Dorine Boudry mentioned. You can simply rename a div with the following statement: document.getElementById('oldName').id = 'newName';

So I just created this javascript action then I call in the onReady event handler and this works perfectly:

Yes ok,

So my thinking was I might be reluctant to do this, because I can't be entirely sure that there is not some platform-generated code that is relying on the id.  So in general, I would be hesitant to change an id that the platform has given to an element.

I made a little demo app to test it out, and turns out that both renaming and adding a child could get into trouble, depending on what else is going on in your screen.  For example, in a scenario where they are part of a container that sometimes has Visible set to false, both the rename and the added child are gone after making them visible again.

See attached demo.

Thinking of it, this makes sense to me in this way : OS has a representation of the screen in react code/variables, and builds the DOM from there, so the dom is not the source but a result of a refresh from the internal state of the screen.  Renaming elements in the dom, or adding child divs to the dom, are not represented in this internal state, and get wiped when OS refreshes the dom.  Something like that, not sure I'm using the right words.

So, conclusion is, both renaming or adding child divs might get lost, you could try doing the rename in the onRender instead of the OnReady.  See attached demo, in that case they are the correct name  after making visible again.

Dorine

It is true to you could get run into collisions, that is something to keep in mind. But I'm sure that as long I put into the documentation that you should not name a container "windy" in the same screen as where you will host this web block that everything will work out find. It is not something that I will worry about especially since I can't do anything about it. It's a requirement from a 3rd party component that our business wants to use. We will deal with the accompanying rules.

And wouldn't a change to the Dom result in an OnRender event and therefore run into a continues loop with your suggestion about event handling placement?

Nope,

changing the dom doesn't trigger an OS OnRender event as far as I can tell.  See attached demo.

so if you don't have collision and dont sometimes make it invisible, all will probably be ok with an OnReady.

And it works, I'm happy :) 

This name 'windy' and the fact that its april 1st almost made me think this was a aprils fools day joke :)

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.