No worries. BTW, there is another way of doing it - each request is represented by some object which creates HTTPService and subscribes for the response. Because each instance sends single request, there is no problem to decode the response.
Cheers, Dmitri. --- In flexcoders@yahoogroups.com, "lagos_tout" <[EMAIL PROTECTED]> wrote: > > Thanks, Dmitri. > > This is a great idea. Unfortunately though, in this project, I don't > have control over what's returned by the server, so I can't add the > requestId. > But with your suggestion, you still end up needing to match requestIds > with handlers on the client right? So do you use a massive switch for > that? > Thanks again. > > LT > > --- In flexcoders@yahoogroups.com, "Dmitri Girski" <mitek17@> > wrote: > > > > If I were you, I would simply add the requestId into the server's > > response, so client always knows which request-response pair it > > handles. This idea lies behind most of the transmissions protocols. > > > > Cheers, > > Dmitri. > > > > > > > > --- In flexcoders@yahoogroups.com, "lagos_tout" <lagos.tout@> wrote: > > > > > > Hi, > > > > > > I'm re-using an instance of HTTPService, changing the request > > > arguments to get different responses from the server. But I found > > > that if, for instance, I made 3 calls this way with the > HTTPService, > > > each of the 3 result handlers registered for each call is executed > > > every time a result returned. > > > > > > I solved this by storing a reference to the unique AsyncToken > returned > > > by each service call and matching it to the AsyncToken contained > in > > > each ResultEvent's "token" property in order to determine which > result > > > handler to execute. > > > > > > I'm not terribly happy with this setup. It seems messy. I'd > > > appreciate any suggestions on how I can reuse an HTTPService > instance > > > without ending up with long switch statements with countless "if > > > thisAsyncToken then do thisHandler, else if thatAsyncToken then do > > > thatHandler... and so on". > > > > > > Thanks much. > > > > > > LT > > > > > >
