Hi, Tracy.
Thanks for your response.
It's good to hear that others use this solution. Makes me feel like
it's not just a stop-gap hack.
However, what made me uncomfortable is the idea in OOP that classes
should be open to extension, closed to modification. It's generally a "code
smell" if one keeps having to literally add code to an existing
class in order to add functionality. Especially when the added
functionality bears such a strong resemblance to existing behaviors.
What do you think?
I really like your idea of adding properties to AsyncToken. Is
AsyncToken a dynamic class? Is that how you do it?
Thanks again.
LT
--- In flexcoders@yahoogroups.com, "Tracy Spratt" <[EMAIL PROTECTED]> wrote:
>
> This is a normal pattern. What about it makes you uncomfortable?
You
> are using a single result handler function, correct? The switch()
> statement makes chaining calls easy and facilitates debugging since
a
> single breakpoint or trace() will track all RPC calls. I have found
> that two string properties ("callId", and "nextAction" ) on the
> AsyncToken work for all my needs so far
>
>
>
> An alternative would be to put a callback function in an AsyncToken
> property or use the addResponder() methods. I personally find
those
> solutions "messy".
>
>
>
> Tracy
>
>
>
> ________________________________
>
> From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED]
On
> Behalf Of lagos_tout
> Sent: Friday, October 10, 2008 8:35 PM
> To: flexcoders@yahoogroups.com
> Subject: [flexcoders] Reusing HTTPService
>
>
>
> 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
>
