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:
> >
> > <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.
> >
> >
> >
> > 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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
