HtmlUnit runs dev mode, where the class files have been bytecode rewritten to allow this. But we've talked about the exact same goals John brings up here, and I think it's a good idea worth supporting. It goes along with being able to run stock JUnit TestCases in a JVM without having to bring up the GWT infrastructure.
On Thu, Mar 18, 2010 at 2:45 PM, Joel Webber <j...@google.com> 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 <jdpatter...@gmail.com> 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