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

David Geary clarity.training at GMAIL.COM
Sun May 24 14:38:18 EDT 2009


2009/5/24 Dan Allen <dan.j.allen at gmail.com>

> On Sat, May 23, 2009 at 11:52 PM, Jim Driscoll <Jim.Driscoll at 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.
>
>
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.


>
>>
>>  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.
>

Agreed. That was my original objection. "name" implies nothing. Name of
what?


> 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.


david


>
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://in.relation.to/Bloggers/Dan
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than a week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters.  Please don't hesitate to resend a message if
> you feel that it did not reach my attention.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090524/b423d25d/attachment.html 


More information about the jsr-314-open-mirror mailing list