Prev: using google visualization
Next: Hollywood NetBook™ Webshop
From: Scott Sauyet on 1 Jul 2010 14:03
Asen Bozhilov wrote:
> Scott Sauyet wrote:
>> [ additional requirement for aggregator ]
>
> Probably by these requirements the follow is enough.
>
> function Aggregator() {
>     var that = this;
>     this.data = [];
>     this._count = 0;
>
>     this._handler = function (request, response) {
>         that.data.push({response : response, request : request});
>         request.success = null;
>         that._count--;
>         if (that._count == 0) {
>             this.onComplete();
>         }
>     };
>
> }
>
> Aggregator.prototype = {
>     onComplete : function () {},
>     add : function (request) {
>         this._count++;
>         request.success = this._handler;
>     }
> };
>
> var agg = new Aggregator();
> agg.onComplete = function () {
> // [ ... ]
> };
>
> var req1 = new RequestWrapper(),
>     req2 = new RequestWrapper(),
>     req3 = new RequestWrapper();
>
> agg.add(req1);
> agg.add(req2);
>
> req1.send();
> req2.send();
>
> agg.add(req3);
> req3.send();

This should work well, I think. I would add "request.send();" to the
Aggregator.prototype.add method so we could lose the "reqN.send()"
calls.

I will probably proceed down the path I've discussed earlier in the
thread with Stefan, but that's pretty close to yours.


> The interesting point for me is how do you want to associate response
> data with the requests? And in which order? At my current API they are
> in order of response not in order of adding in `Aggregator'.  With
> your approach with identifiers and mapping in native object you would
> have one problem. You cannot support any order. If you use `for-in'
> for iterating over responses you cannot know in which order they will
> be enumerated, because that is implementation depended.

Honestly, I thought of this as one of the strengths of that approach.
I can arbitrarily assign a handle that labels the response data, the
errors, and the status of each requests. If I find I care about the
order they come in, the Aggregator can easily track that too, but I
don't see that as likely to ever be important. But because I have the
labels, my callback function can work separately with data.yellow,
data.red, etc. as needed.

Right now the one handler I've written for real code is making calls
to several similar systems and simply concatenating and sorting their
output. It replaces code which called the second system in a success
callback to the first AJAX call and the next one in a callback to
that. It was ugly but worked fine for several years, until the first
service failed but the others would still have worked. In my case, I
do need to know the source of the data, so each response item was
tagged with the label ("red", "yellow", "blue" in the example.) What
may be added soon is a backup system for some of the systems checked.
That would be why the scheduled jobs might have to have links back to
the Aggregator: if System A fails, I want to add a call to System A'
to the aggregator. I'm still a little queasy about that part of the
API; it seems a circular dependency that I'd rather not introduce.


> You should reply on these things which I wrote, and probably you would
> get more clever ideas for your API. The general problem is the order
> of response which you expected.

For me, the main thing is to be able to associate the response with
the request when I go to put them together. Order is simply not
important.

Again, thank you for your helpful replies.

--
Scott
First  |  Prev  | 
Pages: 1 2 3
Prev: using google visualization
Next: Hollywood NetBook™ Webshop