Hi John, if your ultimate goal is to get an crawlable/indexable GWT app, you may also want to look at http://code.google.com/web/ajaxcrawling - you can use HtmlUnit or another headless browser technology to create an HTML snapshot server-side and pass that to the crawler.
kathrin On Thu, Mar 18, 2010 at 3:12 PM, Amit Manjhi <[email protected]> wrote: > +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 To unsubscribe from this group, send email to google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
