Andreas Junghans <[EMAIL PROTECTED]> writes:
> Hi Derrell,
>
> Am 26.01.2007 um 15:11 schrieb [EMAIL PROTECTED]:
>
>> Andreas Junghans <[EMAIL PROTECTED]> writes:
>>
>>> Besides, there's already the "callAsyncListeners" method which has
>>> the same purpose as "callAsync" but behaves more "qooxdoo-ish" (using
>>> the standard listener concept where you can add a listener with a
>>> specific "this" context).
>>>
>>> However, I think the callAsyncListeners method needs some rework (I
>>> don't know who implemented it - Derrell?). I don't see an easy way to
>>> find out which server method was called when the result arrives,
>>> which makes it hard to have concurrent asynchronous calls. I think we
>>> should pass something like {result: ..., methodName: ..., id: ...} to
>>> the listeners.
>>
>> Yes, I implemented it. It's in use in the Samba Web Administration Tool in
>> samba4, which uses the Finite State Machine to handle all events.
>>
>> The id is in the result that's passed as data to the listener. In fact, in
>> the "completed" event handler (Rpc.c:311), we verify that it matches the
>> sequence number of the request. Is there something other than this id
>> that's
>> missing? (We've never provided the method name on any async response. I
>> believe it's up to to the caller to save that information, referenced by the
>> id, if the caller needs it.)
>
> I think we're talking about different things. What I mean is this use case:
No, we're talking about the same thing, but you are right.
> Now look at the code in handleRequestFinished that fires the "completed"
> event:
>
> case 2: // async with event listeners
> // Dispatch the event to our listeners.
> if (! ex) {
> eventTarget.createDispatchDataEvent(eventType, result);
>
> What gets passed as event data is the method result (e.g. a string), not the
> whole structure (result, id, etc.).
It's a naming problem. What we get coming in is called "result" and it
contains both an "id" and "result". In the "completed" event of the request,
I hadn't noticed the line that does result = result["result"] which is just
plain nasty as far as maintainability goes (as is evidenced by the fact that I
missed it when adding the asyncListener feature).
So yes, we should be providing the id as well as the string result. We need
to replicate the original: result = { result: result, id: id } and pass that.
It's unlikely that anything other than SWAT is using that yet. It's too bad
this just got released, as the change will not be backward compatible...
I think that fixing the first problem (naming) will allow an easy fix to the
second problem (missing data being sent to final listener). What do you think
of this (untested) patch:
Index: Rpc.js
===================================================================
--- Rpc.js (revision 5907)
+++ Rpc.js (working copy)
@@ -225,6 +225,7 @@
var ex = null;
var id = null;
var result = null;
+ var completeResult = null;
var handleRequestFinished = function(eventType, eventTarget) {
switch(callType)
@@ -239,7 +240,7 @@
case 2: // async with event listeners
// Dispatch the event to our listeners.
if (! ex) {
- eventTarget.createDispatchDataEvent(eventType, result);
+ eventTarget.createDispatchDataEvent(eventType, completeResult);
} else {
// Add the id to the exception
ex.id = id;
@@ -307,18 +308,18 @@
handleRequestFinished("aborted", eventTarget);
});
req.addEventListener("completed", function(evt) {
- result = evt.getData().getContent();
- id = result["id"];
+ completeResult = evt.getData().getContent();
+ id = completeResult["id"];
if (id != this.getSequenceNumber()) {
this.warn("Received id (" + id + ") does not match requested id (" +
this.getSequenceNumber() + ")!");
}
- var exTest = result["error"];
+ var exTest = completeResult["error"];
if (exTest != null) {
result = null;
addToStringToObject(exTest);
ex = exTest;
} else {
- result = result["result"];
+ result = completeResult["result"];
if (refreshSession) {
result = eval("(" + result + ")");
var newSuffix = qx.core.ServerSettings.serverPathSuffix;
Derrell
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
