How to obtain the html DOM ID-s of SmartGWT widgets/layouts

[csillag]

Hi all,

I am trying to integrate a 3rd party JS library into my app. This app can add some fancy decoration to pre-existing html div-s.

For this, I need to get get DOM IDs of the tables/divs my SmartGWT widgets/layouts are rendered into.

How does one do that?

getId(), getElement().getId() does not seem to be doing what one would (naively) expect them do to.

Thank you for your help:

Kristof

[csillag]

OK, I am one step further now:

getDOM().getId() does return a valid dom ID.
There is one problem though: the given id refenreces a DIV which is much smaller than the actual layout. Actually, the DOM element I need is the parent of the referenced element in the DOM tree.

It seems that getDOM() returns something like the top-level content of the given layout, not the layout itself.

So, to get the ID I need, now I use
getDOM().getParentElement().getId().

Is this the intended usage?

Thank you for your help:

Csillag

[Isomorphic]

The right way to do this is to use an HTMLFlow and override getInnerHTML() to supply your own DOM elements with IDs of your choosing.

[csillag]

I do not want to change the DOM elements the SmartGWT widgets render into; they are perfectly fine, I have absolutely no intention to replace the built-in widgets with my own HTML content.

I just need to get the ID of the auto-generated HTML elements.

Is getDOM().getID() not the right way to do this?

Thank you again:

Csillag

[Isomorphic]

Again, the right way to approach this use case (third party JS library drawing inside SmartGWT widgets) is to use an HTMLFlow and override getInnerHTML() to supply your own DOM elements with IDs of your choosing. It is never a good idea to try to reference SmartGWT's automatically generated DOM elements - they are internals, and subject to change at any time.

[csillag]

I am terribly sorry, but it seems that I still could not properly convey the intended use case.

I am working with a JS library that does not draw _inside_ widgets; it's doing decoration _around_ widgets. (Like drawing a burning fire, or adding some jumping lemmings, or whatever.) It does not provide any static widgets; nor does it alter the page flow, or take up any space.

It just takes the referenced pre-existing HTML elements of the page (divs, tables, whatever), reads out the positions and sizes of them, and then draws stuff around them, using a separate layer. (Still leaving the page flow intact.)

So, I still want to use the usual SmartGWT widgets (button, label, listGrid, etc.) placed in the usual SmartGWT layouts (HLayout, VLayout, etc.).

The only assumptions I am making about SmartGWT's automatically generated DOM elements is that they have position and size.

Is it still a bad idea to reference the automatically generated DOM elements in this case?

Thank you:

Csillag

[Isomorphic]

Yes, it's still a bad idea. It's unlikely that whatever library you want to use actually makes only the assumptions you specify (that there is an element with position and size somewhere) as this doesn't explain how its generated content is going to remain with the element as it moves.

If you want to put a decorating frame around a widget, you are probably best off creating an HTMLFlow that shadows the widget's position and size via Resized and Moved events and SmartGWT APIs for retrieving position and size, and instructing your third party library to draw inside that HTMLFlow, as previously indicated.

[csillag]

Yes, it's still a bad idea. It's unlikely that whatever library you want to use actually makes only the assumptions you specify (that there is an element with position and size somewhere) as this doesn't explain how its generated content is going to remain with the element as it moves.

Indeed, it does not follow the movements; I need to call repaint (with the ID of the element) when the element moves. For this, I have to use SmartGWT events. (So I still think that the lib does not make any other assumptions.)

If you want to put a decorating frame around a widget, you are probably best off creating an HTMLFlow that shadows the widget's position and size via Resized and Moved events and SmartGWT APIs for retrieving position and size, and instructing your third party library to draw inside that HTMLFlow, as previously indicated.

This library will _not_ draw anything inside the HTMLFlow (or whatever reference I give it). It does not touch that part of the DOM tree. it will draw several things around the page (in separate, absolutely positioned HTML Canvases, appended to the end of the DOM tree), taking the position and size of the HTMLFlow in consideration.

* * *

So, to make it clear, you are suggesting to create a HTMLFlow and move/resize it together with the widget, and the tell the 3rd party JS to move/resize together with this shadow widget. Is this right?

If yes, then I still don't get the point of the extra redirection here; the introduced HTMLFlow will not do anything, will not contain anything, it will only copy the position of the original widget, and has it's position copied.


* * *

In any case, how do I add a Move handler to a widget? I can see addResizedHandler(), but there is no addMove<whatever> or addReposition<whatever> on the Canvas class...

Thank you for your help, again:

Csillag

[Isomorphic]

If the use case is really strictly limited to drawing absolutely positioned elements around SmartGWT DOM elements that will not be modified, you can use the Canvas.getClipHandle() API to get the outermost DOM elment. This is undocumented and you will need to access it via JSNI. It returns a DOM element - sorry, there's no convenient method to get the ID directly (it exists but is obfuscated).

[csillag]

Thank you! I will do that.

* * *

Now all that is left is how to add a Move element - but I will ask that again in a new thread.

Thank you again:

Csillag