Attaching GWT widgets to elements inside iframes

[DanG]

Can someone explain the way that GWT deals with iframes in this
regard.
If I want to create my own widgets or for that matter, use other
widgets in an iframe.

The situation is that I have cached versions of arbitrary webpages
loaded into iframes (to get around the iframe domain problem)
and then I want my code to annotate these pages in some fashion,
ideally using floating GWT widgets.

I would expect to do something like this.

Document doc = iframe.getFrameDocument(); //wraps up the Document of
an iframe using managed iframe from gwt-ext for now but thinking of
doing this myself later and giving up on ext.
BodyElement body = doc.getBody();
Element div = DOM.createDiv();
body.appendChild(div);
div.setId("id123");
RootPanel panel = RootPanel.get("id123");
//or better would be RootPanel panel = RootPanel.get(div); //but this
is not a public method.
panel.add(firstWidgetOfMany)

But because RootPanel uses Document.get().getElementById(id).cast()
to find the element AND (shock horror) Document.get() assumes there is
only ever one document for a gwt application I don't understand how
one could tie up the elements in the frame to widgets in GWT without
completely rewriting RootPanel and possibly other classes.

I also want to ask what the potential pitfalls with this scenario are
and the GWT event model.
When I create widgets and parent/register them to existing widgets,
will the events that the elements raise find their way back to the GWT
widgets if the elements exist in the iframe?

Am I thinking about this incorrectly? Is it better to create a new
'instance' of GWT inside the iframe and then try and get the parent
and child instances talking together (i imagine this could also cause
problems)? Or is it simply not worth using GWT widget infrastructure
and build my own infrastructure based on DOM elements for this
scenario (a real pity)?

Thanx, Daniel.

[j...@google.com]

Daniel,

The DOM package was updated in 1.6 to deal with all those nasty $doc
assumptions, so you can create and manipulate the DOM in multiple
documents correctly (though it's still tricky, as you have to keep
track of which element belongs to which document). However, the Widget
library was not, as this is largely intractable without a complete
redesign. The problem is that you can't mix elements from different
documents (the browser will throw an exception if you're lucky, or
simply crash if you're not), and the Swing-style construction model
makes this exceedingly difficult (every widget would have to do
something weird like require a RootPanel (or simply a Document) to be
passed into to its ctor so that it could create its elements in the
right document; even then it would be very difficult to deal with
widgets being moved from one document to another).

The browser event model unfortunately doesn't provide any useful way
to aggregate events across frames/documents, either. The current GWT
event model (not part of the DOM module itself, yet) still assumes
that there is only one document at a time. It would be really nice to
have direct native event support in the DOM module itself at some
point, but there are some very difficult memory leak problems to be
solved before that will be feasible (i.e., if Element just had the
standard add/RemoveEventListener() methods, people would start
creating massive memory leaks).

I don't know the details of your application, but my inclination would
be to do as you suggest in the last paragraph and load separate
"instances" of the application into each iframe if you're going to be
doing significant UI within them. You could also try and manipulate
the iframes' DOMs directly, but you'd have to handle events with JSNI
methods, and you'd have to be very careful about leaks.

Cheers,
joel.

[DanGer]

Hi Joel
Thank you for your considered response.
I understand that I'm not in the majority of use cases so it's
understandable why the widget infrastructure emerged in it's current
design. However it's still nice to know that you've read and
understood my problem and confirmed that my take on the situation is
correct because you might have said something like 'oh just use
functionality x y and z' which I might have been unaware of.

Although I understand how two 'instances' might work in the final
javascript code, I'm not sure that hosted mode was designed to cope
with this scenario as it means there would be two instances
simultaneously with different states, a second entrypoint class etc.
At the moment I think I'm going to take a stab at reworking the DOM of
the iframe. This is really akin to building my own widget
infrastructure. I might try branching the GWT code or respective
classes first and see how far I can get with that while I'm feeling
bold.

I hear what you're saying about a solution requiring every widget to
need a constructor that takes in a Document. Although that would be
the most honest solution as it describes the full nature of the
problem, it does make it ugly for the most common use case where
people would not want to have to manage a seemingly redundant Document
instance.

However there is potentially another way.
Given that widgets have the concept of being attached or detached from
the DOM, if the creation of the widget's elements were delayed until
it was added to it's parent, the passing of the Document could be
hidden from the user.

So...
1) All widgets would implement the interface void create(Document doc)
or something similar.
2) The contents of the constructor for all widgets, currently
responsible for the creation of it's elements, would be moved to it's
create(Document doc) implementation.
3) When the widget was added to it's parent panel, then the create
(...) method would be invoked passing the Document of the parent to
the child. This Document would be responsible for element creation.
Likely the parent would call setDocument() first on the widget, so as
to alleviate widget maintainers from having responsibility to store
the document themselves.
4) If a widget had already been created and had div elements linked to
a specific Document, trying to reparent the widget to a different
panel of a different document would throw a GWT managed error, so
you'd never get the case where the browser would have undefined
behaviour or crash.

Further, in order to roll out such a huge change in operation with no
disturbance to existing GWT apps, I'd create a
Widget.DocumentSpecificDelayedCreation static boolean flag defaulted
to false. Under this default mode the create(...) method would be
called in the constructor as per usual with the default Document and
not when the widget was attached to it's parent. This means that no
changes would have to occur at all for existing apps or 3rd party
widgets. It does mean that 3rd party widgets would have to overload an
implementation of create(...) and write their constructors correctly
if they wanted to support this DocumentSpecificDelayedCreation
behaviour.

Quite elegant, no? ;-)

Thanx again for a great product! And with your previous response,
proved even better service!
Regards
Daniel.