GWT 1.5 Now Available

[Bruce Johnson]

Hi everyone,

The GWT team is proud to announce that GWT 1.5 is now officially released!

GWT Home:

    http://code.google.com/webtoolkit/

Download:

    http://code.google.com/webtoolkit/download.html

Announcement:

    http://googlewebtoolkit.blogspot.com/2008/08/gwt-15-now-available.html

Developer's Guide:

    http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5

This has been a big development cycle, and we're really excited about the advancements in GWT over the last year. As always, we're eager to hear your feedback once you've tried this new version.

GWT 1.5 would not have been possible without the immense contributions of code and ideas from the GWT open source community. Thank you, thank you, thank you.

Cheers,

The GWT Team

[Tim]

Congrats! this is a huge achievement!

Tim
http://gwtnow.com

[GeekyCoder]

Congratulation on the final release. It must have long hard work for
the GWT team.

[Thomas]

Terrific!!!
Just I get a 404 file not found error when I try to download the Linux
version (hope this is temporary...) but anyway thanks a lot for all
the neat new features :)
Tom

[walshms]

One link refers to a tar.gz, another to a tar.bz2...

Here's the working one:
http://google-web-toolkit.googlecode.com/files/gwt-linux-1.5.2.tar.bz2

[pohl]

> Cheers,
> The GWT Team

I wanted to thank the GWT team for all of the hard work that went into
this cycle. You're all rock stars in my book.

[rakesh wagh]

great milestone achievement. Entire gwt community was looking fwd for
this release. congrats gwt team for all the hard work put in.

Cannot wait to see what features are planned for 1.6 :)

Rakesh Wagh

[Arthur Kalmenson]

Congratulations! Although I've been using 1.5 for some time now, it's
always nice to have a final release. Great work, 1.5 is a huge step
forward. Thanks you for all the hard work!

Regards,
Arthur Kalmenson

[Joel Webber]

Sorry for the confusion on the Linux download link. The download page should be updated momentarily. In the meantime the .tar.bz2 link below is correct.

[zefix...@googlemail.com]

The linux download link on http://code.google.com/webtoolkit/download.html
is broken, currently pointing to http://google-web-toolkit.googlecode.com/files/gwt-linux-1.5.2.tar.gz

The correct download link would be http://google-web-toolkit.googlecode.com/files/gwt-linux-1.5.2.tar.bz2


Congratulations to the team!

[GeekyCoder]

Hi Bruce,
GWT documentation is great and informative. Is there a plan to access
doc offline instead of keep accessing the web ? It will be good if the
doc comes in download ?
Browsing document offline is very useful in place where internet
access is not available etc in plane, in customer's site where public
internet access is prohibited.

Although I think that the main reason why information is kept online
is to facilitate information update, I'm sure developers will rather
have quick access to offline documentation. When I read through the
doc, I find that the current information is good and current enough
for developer, so I wonder if the current documentation can be made
available for offline browsing.

thx...

[Ed]

Amazing... impressive that the final is already out shortly after RC1
and RC2...

Also very currious to the roadmap of 1.6. and further...

Thanx...

[Ian Bambury]

Another (definitely 'Breaking') change in 1.5.2 from 1.5.1 is that

 

public final native String getAttribute(String name) /*-{
    return this.getAttribute(name);
  }-*/;

in Element has become

 

public final native String getAttribute(String name) /*-{
  return this.getAttribute(name) || '';
}-*/;

 

i.e. if the attribute does not exist, then for some reason, you don't get the expected null, you get an empty string.

 

Could someone from Google explain why there has been this diversion from the path of 'least surprise'? What suddenly became so wrong with returning what JS gives you? Could you mention it in the release notes as a breaking change? It breaks any number of my apps, all of which check for null, because that's what you used to get.

 

As for the other, unfixed problems, surely a release candidate is a candidate for being released. If it passes, it gets released. If it doesn't pass you change it and put out another release candidate.  I'm a bit surprised that 1.5.2 is 'official'.

 

Ian

[Ian Bambury]

And now I can't tell the difference between an attribute which is missing, and an attribute which is there but empty...

 

Bugger!

[Thomas Broyer]

On Aug 31, 4:00 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> Another (definitely 'Breaking') change in 1.5.2 from 1.5.1 is that
>
> public final native String getAttribute(String name) /*-{
>     return this.getAttribute(name);
>   }-*/;
> in Element has become
>
> public final native String getAttribute(String name) /*-{
>   return this.getAttribute(name) || '';
>
> }-*/;
>
> i.e. if the attribute does not exist, then for some reason, you don't get
> the expected null, you get an empty string.
>
> Could someone from Google explain why there has been this diversion from the
> path of 'least surprise'?

Because that's how the DOM is defined:
http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-745549614

> What suddenly became so wrong with returning what
> JS gives you?

http://code.google.com/p/google-web-toolkit/source/detail?r=3568
Apparently, not all browsers give you nulls.

> Could you mention it in the release notes as a breaking
> change? It breaks any number of my apps, all of which check for null,
> because that's what you used to get.

I'd say that hasAttribute() is missing, but unfortunately, IE doesn't
seem to support it:
http://www.quirksmode.org/dom/w3c_core.html#t95
(at least before IE8: http://msdn.microsoft.com/en-us/library/cc304121%28VS.85%29.aspx
)

IE has a somewhat bizarre getAttribute implementation:
http://msdn.microsoft.com/en-us/library/ms536429(VS.85).aspx
...one that happens to return null when hasAttribute would have
returned false.

On Aug 31, 4:09 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> And now I can't tell the difference between an attribute which is missing,
> and an attribute which is there but empty...

Blame Microsoft eventually at first...
...but having an Element.hasAttribute deferring to
getAttribute()==null in case hasAttribute doesn't exist would probably
be enough to get this "fixed" (or better: deferred binding, which
would also use getAttribute(name, 2) for IE to get the appropriate
behavior)

[Ian Bambury]

2008/8/31 Thomas Broyer t.br...@gmail.com

> Could someone from Google explain why there has been this diversion from the
> path of 'least surprise'?

Because that's how the DOM is defined:
http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-745549614

 

 

No it's not. w3.org's *recommendations" that you link to state that getAttribute() returns the string, or an empty string if the attribute is empty and there is no default. It doesn't appear here to  recommend any return value if the attribute does not exist.

 

> What suddenly became so wrong with returning what
> JS gives you?

http://code.google.com/p/google-web-toolkit/source/detail?r=3568
Apparently, not all browsers give you nulls.

 

That doesn't explain the sudden change.

 

 

On Aug 31, 4:09 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> And now I can't tell the difference between an attribute which is missing,
> and an attribute which is there but empty...

Blame Microsoft eventually at first...

Why is it Microsoft's fault that Google made the change?

 

I'm quite happy to blame Microsoft for anything and everything that has ever or will ever happen (I don't want to look out of place here) but if there is a genuine connection, all the better.

 

The bottom line for me is that IE, FF, Opera and Safari all return null in raw JavaScript if the attribute doesn't exist - I really don't give a monkey's about the other browsers that GWT supports (!?) - and since when have Google worried about being officially compliant over getting the job done?

 

Ian

[Joel Webber]

All,

There is certainly a possibility that this change was a mistake, but it does *not* appear cut-and-dried from reading the spec. Here is the actual text from the DOM spec:

---

getAttribute

  Return Value

    DOMString The Attr value as a string, or the empty string if that attribute does not have a specified or default value.

---

Depending upon how you interpret that (especially the definition of the phrase 'does not have a specified or default value'), you could see it either way. It certainly doesn't specify that you *can* depend upon a null return value to determine that an attribute doesn't exist. In fact, it doesn't even address the definition of a 'non-existent' attribute. You could make the argument that it enumerates the valid types for the return value as "a string, or the empty string", specifically excluding 'null'. Or you could reasonably argue that all browsers *do* return null for undefined attributes. But the reality is that it's not entirely dependable. Let me demonstrate by example:

<div id='foo'>

var foo = document.getElementById('foo');

getAttribute('id')

  IE7: foo

  Firefox3: foo

getAttribute('className')

  IE7: ""

  Firefox3: null

getAttribute('tabIndex')

  IE7: 0

  Firefox3: null

getAttribute('xxx')

  IE7: null

  Firefox3: null

This puts us between a rock and a hard place. If we allow developers to depend upon the return value being null, it won't always work. Do we then have to put an explicit test in getAttribute() to force a null return value in weird corner cases like tabIndex and className?

The only thing that appears clear to me in the spec is that you should probably call hasAttribute() if you're not sure whether it's there or not -- which we would need to add to Element (and implement somehow on IE, since it's not there by default). I would also be willing to consider changing the type-coercion in getAttribute(), but only with the strong caveat that its behavior is not specified when the attribute is 'not specified'.

Cheers,

joel.

[lups]

Who is able to publish this wonderful version on the Maven 2
repository (http://repo1.maven.org/maven2/com/google/gwt/) ?
I can find four old 1.5 versions of GWT, but nor the final 1.5.2
release.
Many thanks
Bernard

[GeekyCoder]

Joel,
can a overloaded method be added too ?

public final native String getAttribute(String name, boolean
returnNullIfNotFound)

so that getAttribute(String name) return the current behaviour as
return by browser so that for those who program browser-specific code
can handle it.

and For those who want to maintain single code base, setting a flag
will force it to return null if attribute is not found.

It will be too verbose to do the following check.

String _i = (hasAttribute("xxx") ? getAttribute("xxx") : null); //
or use a if


This will be good.
String _i = getAttribute("xxx", true);

> On Sun, Aug 31, 2008 at 7:04 PM, Ian Bambury <ianbamb...@gmail.com> wrote:
>
> > 2008/8/31 Thomas Broyer t.bro...@gmail.com

[lups]

Thanks, somebody has published gwt 1.5.2 on maven repo...

[JohnnyGWT]

Congrats!

So, is GWT 1.5 now considered production ready? I'm working a project
that is approximately 60% done.
Should I now update to 1.5?

[AJ]

Sadly it was uploaded without the source (or javadoc), so the Maven
release seems a bit crippled for development usage.

[Joel Webber]

The problem with 'returnNullIfNotFound' is that it's a contract we can't guarantee will be honored. IE (and possibly others, though I'm not certain) will definitely return non-null (and apparently non-string in some instances) values for unspecified attributes at times. How could we guard against that?

It might seem a little verbose to have to write

 e.hasAttribute("foo") ? e.getAttribute("foo") || null;

but I can practically guarantee that any code we have to make the return value of getAttribute() correctly null will be at least as expensive.

We also have to figure out how to implement hasAttribute() on IE, which is not there by default. Ideas on that front welcome (e.g., we need to correctly implement Element.hasAttribute("tabIndex"), which on IE simply returns "0", even if it was never specified).

Cheers,

joel.

[Ian Bambury]

Thing is that the attribute *is* there because IE adds them with a default (or returns a default by, err, default). Which makes sense for at least some of the attributes, e.g. width - if it doesn't have a width of something, then it has a width of nothing, whether the programmer has set it or not. It makes coding more concise and doesn't break the recommendations because defaults are allowed.

 

So it would seem easier to return an empty string/zero for non-IE browsers when requesting a known style attribute (i.e. emulate IE on other browsers) and return null for non-existent user-defined attributes. The alternative is to keep your own list ow what has been explicitly or implicitly set - good luck with that if you choose that route :-)

 

You can't just return a blank string for any attribute, even non-existent ones because it is a) dangerous (because a typo will still give you a valid return where a null will raise an exception or at least be noticably wrong) and b) is unexpected/surprising because it's not what *any* browser does.

 

What I don't understand is why an undocumented breaking change was added in at the last moment to what was an accepted release candidate. Surely a release candidate if accepted goes out unchanged or it's not so much a candidate for release, more of "a candidate for a bit of tweaking before we send it out untested by the people we release RCs to". If that's the case, be honest and call it a beta :-P

 

Ian

2008/9/4 Joel Webber <j...@google.com>

Internet communications are not secure and therefore I will not accept legal responsibility for the contents of this message.
Any views or opinions do not necessarily represent what I really think unless otherwise specifically stated, and even then, I
might still be lying. This message may contain confidential privileged information, but if it does, I've nicked it from someone
else. If you have received this email in error then tough, hit delete, and don't bother me about it, I really don't care. Batteries
not included. Contents can go up as well as down. Shares can vary in size. May cause drowsiness, if affected, go to sleep.
=========================================================================================

[Reinier Zwitserloot]

I transferred tipit.to over to the new code base, and that's from a
GWT 1.4 that was custom patched with a couple of pretty deep hacky
bits in it. I had scheduled a week for transfer and testing, but it
wasn't nearly as bad. Give it a try, in other words!

> --
> Ian
>
> http://examples.roughian.com
>
> =========================================================================== ==============

[Joel Webber]

Ian,

What has happened here is that we've been caught between slightly unpredictable, but useful, behavior -- and a specification that seems to be in contradiction with said behavior. We may have underestimated the impact of this change, seeing it as a tweak to be closer to the actual specification. What I think we need here is to finish the implementation of the DOM spec by adding Element.hasAttribute(), which is unambiguously defined and will allow us to avoid any confusion about the return value of getAttribute(). I've added issue 2852 to capture this.

Cheers,

joel.

[Thomas Broyer]

On 1 sep, 18:46, "Joel Webber" <j...@google.com> wrote:
> All,
> There is certainly a possibility that this change was a mistake, but it does
> *not* appear cut-and-dried from reading the spec. Here is the actual text
> from the DOM spec:
>
> ---
> getAttribute
>   Return Value
>     DOMString The Attr value as a string, or the empty string if that
> attribute does not have a specified or default value.
> ---
>
> Depending upon how you interpret that (especially the definition of the
> phrase 'does not have a specified or default value'), you could see it
> either way.

Given that the DOM explicitly calls out nulls everywhere, I think it's
pretty clear what the intended reading is here.
Add to that some definitions taken from elsewhere in the same doc:

---
Interface Attr
[...]
The attribute's effective value is determined as follows: if this
attribute has been explicitly assigned any value, that value is the
attribute's effective value; otherwise, if there is a declaration for
this attribute, and that declaration includes a default value, then
that default value is the attribute's effective value; otherwise, the
attribute does not exist on this element in the structure model until
it has been explicitly added.
---
i.e. an attribute's value cannot be 'null'.

document.createAttribute("foo") for instance creates an attribute with
an empty-string value, not null.

Some more quoting:
---
getAttributeNode
Return Value
Attr The Attr node with the specified name (nodeName) or null if
there is no such attribute.
---
Given that getAttribute is defined in term of "Attr", there must be an
Attr returned for getAttributeNode with the same parameter. It follows
that getAttribute() returns an empty string when getAttributeNode()
would return null.

> It certainly doesn't specify that you *can* depend upon a null
> return value to determine that an attribute doesn't exist. In fact, it
> doesn't even address the definition of a 'non-existent' attribute. You could
> make the argument that it enumerates the valid types for the return value as
> "a string, or the empty string", specifically excluding 'null'. Or you could
> reasonably argue that all browsers *do* return null for undefined
> attributes.

What do mean "non-existent attribute" and "undefined attributes"? Are
you talking about attributes that aren't valid on an element per some
DTD or schema? The DOM doesn't deal with validation (but it deals with
attribute declarations and thus default values).
Otherwise, either an Element contains some Attr with a given name in
its 'attributes' NamedNodeMap property, or it doesn't. Such an Attr
can either exist because it has been "specified" (present in the
markup when parsed, or added later by setAttribute/setAttributeNS or a
combination of createAttribute/createAttributeNS and either
setAttributeNode/setAttributeNodes or attributes.setNamedItem/
setNamedItemNS) orbecause there's a declaration assigning it a default
value.

> But the reality is that it's not entirely dependable. Let me
> demonstrate by example:
>
> <div id='foo'>
>
> var foo = document.getElementById('foo');
> getAttribute('id')
>   IE7: foo
>   Firefox3: foo
> getAttribute('className')
>   IE7: ""
>   Firefox3: null
> getAttribute('tabIndex')
>   IE7: 0
>   Firefox3: null
> getAttribute('xxx')
>   IE7: null
>   Firefox3: null

Try this:
<!DOCTYPE html>
<script src="http://json.org/json2.js"></script>
<script>
function test() {

var foo = document.getElementById("foo");

var attrNames = ["id", "ID", "className", "class", "tabIndex",
"tabindex", "xxx", "x", "href", "target"];
for (var i=0,l=attrNames.length; i < l; i++) {
var attrName = attrNames[i];
w(attrName + ": "
+ JSON.stringify(foo[attrName]) + ", "
+ JSON.stringify(foo.getAttribute(attrName)) + ", "
+ JSON.stringify(foo.getAttribute(attrName, 1)) + ", "
+ JSON.stringify(foo.getAttribute(attrName, 2)) + ", "
+ JSON.stringify((foo.getAttributeNode(attrName) ||
{nodeValue:""}).nodeValue));
}
}
</script>
<body onload="test()">
<a id="foo" href="document" x="" class="bar"></a>


IE7:
log: id: "foo", "foo", "foo", "foo", "foo"
log: ID: undefined, "foo", null, "foo", "foo"
log: className: "bar", "bar", "bar", "bar", ""
log: class: undefined, null, null, null, "bar"
log: tabIndex: 0, 0, 0, 32768, 0
log: tabindex: undefined, 0, null, 32768, 0
log: xxx: undefined, null, null, null, ""
log: x: "", "", "", "", ""
log: href: "http://software.hixie.ch/utilities/js/live-dom-viewer/
document", "http://software.hixie.ch/utilities/js/live-dom-viewer/
document", "http://software.hixie.ch/utilities/js/live-dom-viewer/
document", "document", "http://software.hixie.ch/utilities/js/live-dom-
viewer/document"
log: target: "", "", "", "", ""


FF3:
log: id: "foo", "foo", "foo", "foo", "foo"
log: ID: undefined, "foo", "foo", "foo", "foo"
log: className: "bar", null, null, null, ""
log: class: undefined, "bar", "bar", "bar", "bar"
log: tabIndex: 0, null, null, null, ""
log: tabindex: undefined, null, null, null, ""
log: xxx: undefined, null, null, null, ""
log: x: undefined, "", "", "", ""
log: href: "http://software.hixie.ch/utilities/js/live-dom-viewer/
document", "document", "document", "document", "document"
log: target: "", null, null, null, ""


Particularly, compare:
- the first and second column on IE7 results
- the fourth column in IE7 results with the second column in FF3
results

The last column is my interpretation of the the DOM.

Net results:
As I previously said, IE's getAttribute(..., 2) is equivalent to FF3's
getAttribute, except for tabIndex and className (these are known IE
quirks).
IE's getAttributeNode() is known to return null only for attributes
that would be invalid (for valid attributes, it returns an Attr,
whether or not the attribute has a default value per HTML's DTD).

Found on http://fluidproject.org/blog/page/2/ here's a workaround for
hasAttribute():
var attr = elem.getAttributeNode("tabindex");
return attr ? attr.specified : false;
...well, except for those cases where the Attr has a default value...
Maybe this would work (untested):
var attr = elem.getAttributeNode("tabindex");
return attr ? attr.specified || !!attr.value : false;
(except for cases where the default value is the empty string...)

See also http://tobielangel.com/2007/1/11/attribute-nightmare-in-ie

[Ian Bambury]

2008/9/5 Thomas Broyer t.br...@gmail.com

--

Interface Attr
[...]
The attribute's effective value is determined as follows: if this
attribute has been explicitly assigned any value, that value is the
attribute's effective value; otherwise, if there is a declaration for
this attribute, and that declaration includes a default value, then
that default value is the attribute's effective value; otherwise, the
attribute does not exist on this element in the structure model until
it has been explicitly added.
---
i.e. an attribute's value cannot be 'null'.

document.createAttribute("foo") for instance creates an attribute with
an empty-string value, not null.

 

I don't think anyone is suggesting that an attribute holds a null.

 

The question is: what do you return when trying to get the value of an attribute that doesn't exist?

 

<div question="Life, The Universe, and Everything"></div>

 

String answer = elem.getAttribute("answer");

 

It doesn't hold a value.

It doesn't hold an empty string.

It's not null either because it doesn't exist.

 

But in this case, all the browsers I looked at (IE/FF/Safari/Opera/Chrome), in JavaScript, return a null and now, suddenly, between 1.5.1 and 1.5.2, GWT decided to go its own way and return an empty string. And break my programming. (To be fair, I don't think Google made a decision to break my programs, but on the other hand, there was no consultation with the user-base of this open-source framework, it just got put in and sent out on the quiet.) 

 

The difference between the browsers is when it comes to explicit attributes - MS has the rule:

 

             "Returns a string, a number, or a Boolean, defined by sAttrName. If an explicit attribute doesn't exist, an empty string is returned. If a custom attribute doesn't exist, null is returned."

 

which makes more sense to me as it involves less coding in situations like className where you are never going to worry about whether it's been set ot not, just what it is, but will return null if a custome attribute has not been set or if you make a typo.

 

If you *don't* return a null for custom attributes, then people will have no indication that getAttribute("float") is probably not what they were after.

 

Ian

[Sumit Chandel]

Hello everyone,

The GWT 1.5 Breaking Changes doc has been updated to mention the change in return values for non-existing attributes in an Element.getAttribute(name) call to make sure this doesn't catch anyone unawares.

GWT 1.5 Breaking Changes:

http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=ReleaseNotes_1_5_BreakingChanges

In the meantime, Joel has entered Issue #2852 to try to make checking for a specific attribute less ambiguous by introducing an Element.hasAttribute(name) method. This seems like a needed method anyway to complete compliance with the current DOM spec.

Issue #2852:

http://code.google.com/p/google-web-toolkit/issues/detail?id=2852

However, it's very likely that the reimplementation of the Element.getAttribute(name) method was a bad move on the team's part, so I would suggest we start a new thread on the GWT Contributors group to see whether the new empty string return is a bad decision and whether we should revert to the old contract of returning null for non existing element attributes.

Cheers,

-Sumit Chandel

[Schimki86]

Maybe you know the "Bug", that the ScrollPanel doesn't work inside an
TabPanel, because it grows up instead showing scrollbars. Now we are
about to update from GWT 1.5.1 to version 1.5.2. Someone knows whether
the error still occurs in the fianlen version? It would help a lot! I
need this inside a TabPanel...

[Riyaz Mansoor]

This bug still exists in 1.5.2

Actually I didn't know it was a bug - except when I saw this post :)

[vector]

Hi.
I have tried to download latest version for windows. The file is
corrupted. I performed it from several places, but result is always
the same.

[Reinier Zwitserloot]

It's not, there's a known problem with the google download link, for
some people it just screws up. I suggest you try to download it from
another network.

[vector]

Thanks a lot. I succeed in downloading at length. Absence of staff and
free channel done its work ;-).