Re: GWT 1.5 Now Available
I've the offline docs :-) On Aug 29, 9:48 pm, GeekyCoder <[EMAIL PROTECTED]> wrote: > 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... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
Thanks a lot. I succeed in downloading at length. Absence of staff and free channel done its work ;-). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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. On Sep 18, 12:52 pm, vector <[EMAIL PROTECTED]> wrote: > 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
This bug still exists in 1.5.2 Actually I didn't know it was a bug - except when I saw this post :) On Sep 12, 1:26 pm, Schimki86 <[EMAIL PROTECTED]> wrote: > 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... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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 On Fri, Sep 5, 2008 at 12:54 PM, Ian Bambury <[EMAIL PROTECTED]> wrote: > > > 2008/9/5 Thomas Broyer [EMAIL PROTECTED] > >> >> -- >> 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? > > > > 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 > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
2008/9/5 Thomas Broyer [EMAIL PROTECTED] > > -- > 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? 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
On 1 sep, 18:46, "Joel Webber" <[EMAIL PROTECTED]> 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: > > > > 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: http://json.org/json2.js";> 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)); } } 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, "", "", "", ""
Re: GWT 1.5 Now Available
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. On Thu, Sep 4, 2008 at 10:05 AM, Ian Bambury <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> > >> 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. >> >> On Mon, Sep 1, 2008 at 5:12 PM, GeekyCoder <[EMAIL PROTECTED]> wrote: >> >>> >>> 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 Sep 2, 12:46 am, "Joel Webber" <[EMAIL PROTECTED]> 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. 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.
Re: GWT 1.5 Now Available
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! On Sep 4, 4:05 pm, "Ian Bambury" <[EMAIL PROTECTED]> wrote: > 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 <[EMAIL PROTECTED]> > > > > > 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. > > > On Mon, Sep 1, 2008 at 5:12 PM, GeekyCoder <[EMAIL PROTECTED]> wrote: > > >> 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 Sep 2, 12:46 am, "Joel Webber" <[EMAIL PROTECTED]> 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. 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: > > >> > > > >> > var foo = document.getElementById('foo'); > >> > getAttribute('id') > >> > IE7: foo > >> > Firefox3: foo > >> > getAttribute('className') > >> > IE7: "" > >> > Firefox3: null > >> > getAttribute('
Re: GWT 1.5 Now Available
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 <[EMAIL PROTECTED]> > 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. > > On Mon, Sep 1, 2008 at 5:12 PM, GeekyCoder <[EMAIL PROTECTED]> wrote: > >> >> 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 Sep 2, 12:46 am, "Joel Webber" <[EMAIL PROTECTED]> 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. 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: >> > >> > >> > >> > 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 spe
Re: GWT 1.5 Now Available
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. On Mon, Sep 1, 2008 at 5:12 PM, GeekyCoder <[EMAIL PROTECTED]> wrote: > > 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 Sep 2, 12:46 am, "Joel Webber" <[EMAIL PROTECTED]> 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. 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: > > > > > > > > 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. > > > > > > > > On Sun, Aug 31, 2008 at 7:04 PM, Ian Bambury <[EMAIL PROTECTED]> > wrote: > > > > > 2008/8/31 Thomas Broyer [EMAIL PROTECTED] > > > > >> > 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" <[EMAIL PROTECTED]> wrote: > > >> > And now I can't tell the difference between an attribute which is > > >> missing, > > >> > and an attribute which is there but empty... > > > > >> Blam
Re: GWT 1.5 Now Available
Sadly it was uploaded without the source (or javadoc), so the Maven release seems a bit crippled for development usage. On Sep 2, 10:43 am, lups <[EMAIL PROTECTED]> wrote: > Thanks, somebody has published gwt 1.5.2 on maven repo... > > On 1 sep, 11:37, lups <[EMAIL PROTECTED]> wrote: > > > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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? On Aug 28, 6:44 pm, "Bruce Johnson" <[EMAIL PROTECTED]> wrote: > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
Thanks, somebody has published gwt 1.5.2 on maven repo... On 1 sep, 11:37, lups <[EMAIL PROTECTED]> wrote: > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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 Sep 2, 12:46 am, "Joel Webber" <[EMAIL PROTECTED]> 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. 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: > > > > 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. > > > > On Sun, Aug 31, 2008 at 7:04 PM, Ian Bambury <[EMAIL PROTECTED]> wrote: > > > 2008/8/31 Thomas Broyer [EMAIL PROTECTED] > > >> > 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" <[EMAIL PROTECTED]> 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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: 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. On Sun, Aug 31, 2008 at 7:04 PM, Ian Bambury <[EMAIL PROTECTED]> wrote: > > > 2008/8/31 Thomas Broyer [EMAIL PROTECTED] > >> >> > 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" <[EMAIL PROTECTED]> 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 > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
2008/8/31 Thomas Broyer [EMAIL PROTECTED] > > > 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" <[EMAIL PROTECTED]> 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
On Aug 31, 4:00 pm, "Ian Bambury" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
And now I can't tell the difference between an attribute which is missing, and an attribute which is there but empty... Bugger! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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. On Fri, Aug 29, 2008 at 9:38 AM, walshms <[EMAIL PROTECTED]> wrote: > > 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 > > On Aug 29, 3:21 am, Thomas <[EMAIL PROTECTED]> wrote: > > 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 > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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 On Aug 28, 8:44 pm, "Bruce Johnson" <[EMAIL PROTECTED]> wrote: > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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 On Aug 28, 7:44 pm, "Bruce Johnson" <[EMAIL PROTECTED]> wrote: > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
> 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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 On Aug 29, 3:21 am, Thomas <[EMAIL PROTECTED]> wrote: > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
Congratulation on the final release. It must have long hard work for the GWT team. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
Congrats! this is a huge achievement! Tim http://gwtnow.com On Aug 28, 8:44 pm, "Bruce Johnson" <[EMAIL PROTECTED]> wrote: > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
GWT 1.5 Now Available
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---