+1 to both Ray and Scott's answers. On Thu, Mar 18, 2010 at 11:59 AM, Ray Ryan <[email protected]> wrote:
> It doesn't come up with HTMLUnit because from the GWT point of view > HTMLUnit is just another browser. Prod mode is a non-issue, and for dev mode > we have the moral equivalent of a browser plugin for it. > > On Thu, Mar 18, 2010 at 11:45 AM, Joel Webber <[email protected]> wrote: > >> John, >> >> The background behind that weird type hierarchy is that it stems from a >> time before overlay types existed. Originally c.g.g.user.client.Element was >> a simple opaque handle that had to be passed to the DOM.*() methods to get >> anything done (same for Event). After the compiler got overlay type support >> we added c.g.g.dom.client.Element as a superclass to user.Element, and >> refactored all the DOM.*() methods to use the new dom.* node/element >> hierarchy. >> >> Unfortunately we couldn't banish user.Element altogether without breaking >> everyone, so we ended up with a number of warts like >> setElement(user.Element). It's been on our TODO list for some time to >> deprecate user.Element and remove all references to it, but no one's found >> the time yet. As you've probably discovered, we just end up using JSO.cast() >> to work around this where necessary, but of course that won't work in "real" >> Java. >> >> If I understand what you're doing correctly, it sounds like clearing this >> up would simplify your life. But it might take a while, because we have to >> go through a fair amount of work to get there. >> >> @kathrin & amit: How did you guys deal with this in the HtmlUnit testing >> stuff? Sounds like it would have come up there. >> >> Cheers, >> joel. >> >> >> On Thu, Mar 18, 2010 at 12:45 AM, jd <[email protected]> wrote: >> >>> Hi, >>> >>> I am reposting this question here as the user list got no reply and I >>> guess it is more a dev question: >>> >>> I am experimenting with compiling GWT code with a standard JDK so I >>> can use the same code to generate HTML on both the client and the >>> server. So far it seem to be working OK but will only be practical if >>> I can also get UIBinder and i18n working. >>> >>> My goal is to create HTML pages that can be crawled and indexed and >>> also allow GWT code to add, load and modify the page. Others have >>> recommended building two parallel sites - an html one and a GT one >>> which seems a bit redundant. >>> >>> My experiement has put a real w3c Node inside every GWT Node and >>> replace native methods with ones that manipulate the w3c node. Then >>> finally I take the full w3c node from any element and convert it into >>> html. >>> >>> I found that the object hierarchy needed to be changed to be valid >>> Java. An example of the issue is with the Anchor widget: >>> >>> public Anchor() { >>> setElement(Document.get().createAnchorElement()); >>> setStyleName("gwt-Anchor"); >>> } >>> >>> com.google.gwt.dom.client.AnchorElement extends >>> com.google.gwt.dom.client.AnchorElement but setElement expects a >>> com.google.gwt.user.client.Element so AnchorElement must extend both >>> classes which is impossible. >>> >>> >>> I have modified AnchorElement and friends to extends >>> com.google.gwt.user.client.Element instead which seems to have >>> worked. >>> >>> >>> My question is: Is this impossible inheritance hierarchy intentional >>> to stop this kind of messing about? >>> >>> Cheers, >>> >>> John >>> >>> -- >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >>> >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
