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 <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
