On Sat, May 23, 2009 at 11:52 PM, Jim Driscoll
<Jim.Driscoll@sun.com> wrote:
On 5/23/09 10:46 AM, David Geary wrote:
The onevent attribute of <f:ajax> can be used to specify a JS function
to monitor Ajax calls, which is all well and good. However, the data
payload (I'm not sure why we have to refer to it as a payload), seems
strange because:
1. data.type is always "event". What's the point of that?!?
Sometimes, it's error. See the jsf-demo/ajax-queue demo for an example that uses this interchangeably.
2. 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.
The name of the event. Or, the name of the error. The spec lists them - there are only a few to choose from. I'm afraid I don't understand your objection.
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?
-Dan