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. On May 7, 10:44 pm, [email protected] wrote: > 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. > > On May 7, 3:51 pm, DanG <[email protected]> wrote: > > > 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
