[jsr-314-open] data payload for ajax calls

[Jim Driscoll]

On 5/24/09 11:38 AM, David Geary wrote:
> Okay, that makes sense, I suppose. But the spec, in table 14-4 describes
> the value of the type parameter as simply "event". That description
> should be updated.



You need to also see table 14-6.


>             2. data.name <http://data.name> <http://data.name> is really
>             the status of the Ajax
>
>             request. Using "name" for the property seems meaningless.
>             Name of what?
>
>
>
>     Honestly, in looking at the demo you cited, I can't possibly resolve
>     why you would want to use a property called "name". To me, the word
>     "status" wants to come to mind. I really think you could get away
>     with a single property, status.
>
>     status could be: begin, complete, success, error
>     Then you have errorCode instead of overloading name. Just get rid of
>     type and name and use status instead.
>
>
> Agreed. That was my original objection. "name" implies nothing. Name of
> what?

The name of the event.  Or, the name of the error.



>             3. does it make sense to give the page author acdcess to the
>             actual
>
>             XMLHttpRequest object via the data payload? data.xhr, for
>             example?
>
>
>         Is your objection that they could modify the object?  Since this
>         is JavaScript, they can already modify darn near everything
>         anyway.   We could always deliver them a copy of the object, I
>         suppose...
>
>
>     I think David is asking whether it is possible to access the object.
>     It appears that data is a copy of the properties from the XHR
>     object, not the object itself. David, do you want the native object?
>
>
> Yes, I think it'd be useful to provide access to the actual xhr object.


That would require a spec change.  The motivation for leaving that out 
(I'd originally had it in the payload) was mostly just that folks in 
general didn't think that people would want to use that.  I also got 
some resistance (as I recall) to the response text - but at least one 
use case (improved error reporting) was envisioned for it, so it stayed in.

Again, I really wish this had come up when the spec went up for review, 
instead of now that it's final, but at least this change (adding a new 
property to an object) isn't a break with current compatibility.

Jim