Sorry for the thread necromancy, but aside from https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion this was the only relevant existing conversation I could find on the topic.
In GWT 2.6 user.client.Element was finally deprecated, though done in a way to avoid any backward compatibility breakage. For example, UiObject now has two setElement methods, one for user.client.Element and another for dom.client.Element. However, UiObject.getElement still returns user.client.Element, as do a few other methods, as of master when I write these words. I'm submitting a patch that first amends UiObject.getElement and SimplePanel.getContainerElement to return dom.client.Element. My thinking is that we need an API-breaking release which still holds user.client.Element, but doesn't actually use them, allowing downstream libraries or projects to be compatible with more than one release. The alternatives as I'm currently seeing them, after deprecating in an initial release a) force a big jump, removing all traces of user.client.Element at once, meaning a library that is compatible with 2.x may not be compatible with 2.x+1. Not ideal (as a downstream library author, who doesn't want to force users to only support a single version of GWT at a time, as bugs do happen, even in GWT), but certainly easier to maintain. b) do this two-step dance, making API breakage twice, but with the goal of shifting to the new API within GWT itself (and encouraging it downstream), then a version later removing the old one. Any library/project compatible with N is then compatible with N+1 in as many cases as possible. If we like b), I'd leave any static DOM methods, but dig in further and hit any overridable methods. If a) is preferred, we can just cut to the chase and remove user.client.Element entirely today. Initial patch (subject to later discussion) is at https://gwt-review.googlesource.com/9514. On Monday, December 21, 2009 5:10:47 PM UTC-6, Thomas Broyer wrote: > > Hi Googlers, > > How about deprecating c.g.g.user.client.Element and > c.g.g.user.client.DOM altogether and "port" all existing widgets to > c.g.g.dom.client.*? > A first "pass", say in 2.1, wouldn't break public APIs, still using > c.g.g.user.client.Element as public and protected methods' return type > and fields; only the second pass (in 2.2 or even 2.3) would completely > get rid of c.g.g.user.client.Element. > > As for c.g.g.user.client.DOM, there are a few methods that have no > equivalent in c.g.g.dom.client.* (getChild/insertChild/etc. for > instance, which deal with child elements, not child nodes). Those > would have to either be moved to c.g.g.dom.client.Element or removed > altogether in the end (which means "deprecated with replacement API" > vs. "just deprecated" in the mean time). > Most widgets have complete control over their DOM, so changing from > "child element" to "child node" shouldn't break them. > > I volunteer to providing patches (probably one widget at a time), but > I'd like to know upfront if I'd waste my time or if it'd have a chance > of being accepted. > > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/04e16fb1-6fd5-456f-b421-771c6761da86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
