Dealing with listeners for an asynchronous proxy method

[jamesmcness]

Hi,
I'm having trouble working out which is the best way to go about my project. I have a proxy that is providing access to data via a web service. Obviously this is asynchronous, so I have 3 potential listeners that I need to attach - SUCCESS, ERROR and PROGRESS.

This proxy is specifically allowing access to user data, however the web service has been set up to retrieve the data in different specific requests, so there might be 10 or more different sorts of webservice calls that need to be made on demand. It seems like overkill making a unique SUCCESS, ERROR and PROGRESS notification for each of these 10 different request types.

So here's my question, is it bad form to attach mediator based event listeners that are fed to the proxy when it makes the webservice call? These events would then bypass the notification system and communicate directly with the Mediator that has made the request...

[puremvc]

Yes, it is bad form to have the mediators setting event listeners on the services. It does not fall within the Mediator's responsibility set.

You probably need more Proxies. I don't know the business of your app, but even if you only have one service endpoint, it is unlikely that your 10 separate requests are going to be for the same data type.

If you're fetching users and their payroll deductions and their days off and their hat size all through the same service, you probably want to engineer the thing with one delegate class that knows the service and a Proxy for each of the distinct data types that are being returned.

The Proxies would all use the same delegate to communicate with the service but invoke different methods on it. And if you play your cards right, you can make an AbstractProxy that extends Proxy, provides the onFault and onProgress methods and is extended by the other Proxies, which need only provide success handlers for their particular set of service methods.

-=Cliff>