This is a good idea and exactly what I'm going to try now. This will cover about 98% of my commands, and will have the advantage of both faults coming from the operations and the service level to have the same handler.
I guess at this point, I really want to understand the AsyncToken stuff in relation to Cairngorm design, so I think I'll post over to the cairngorm list. It's probably really a best practices that I'm looking for. Thanks Tracy for the suggestinos. --- In [email protected], "Tracy Spratt" <[EMAIL PROTECTED]> wrote: > > So can you leave the fault handler on the service and not user the ones > on the operations? Or point those to some dummy handler? > > Tracy > > > > ________________________________ > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Todd > Sent: Thursday, October 16, 2008 3:25 PM > To: [email protected] > Subject: [flexcoders] Re: WebService operation faults propigating up to > WebService fault handler. > > > > Hmmm...interesting. > > I got into the Responders/AsyncTokens because that's how all the > Cairngorm samples were setup. > > But with what you say, it's very consistent with all the samples using > MXML WebServices...putting a fault on the operation. But with faults > on the operation, what happens when Flex can't even call the operation > because of a SOAPEncoder error? > > Originally, all was fine with using Responders, but then I noticed > that errors from the SOAPEncoder were getting swallowed, and when Flex > tried building a SOAP message, but couldn't because of some improper > format, nothing would happen. It would sit there. Adding an error > handler to the actual service solved that. > > Now, however, I'm stuck with Responder's handling faults, and the > actual WebService handling faults. I'd like to at least not have the > Web Service fault trigger if the responder handled it. > > I'm about 12 Web Services, 140+ calls into this thing. I don't think > it'll be possible for me to get rid of my Responder cairngorm > infrastructure...but I'd like to at least get a handle on how/where > the faults are raised from. > > Had I done this again, I'd probably take your approach of having a > single handler, use that as the master that subs things out depending > upon the type of response. This would have the benefit of a single > point in dealing with the Flex services layer... > > --- In [email protected] <mailto:flexcoders%40yahoogroups.com> > , "Tracy Spratt" <tspratt@> wrote: > > > > Do you need the fault handler on the operation? I typically a single > > fault handler for all operations. I also use a single handler for all > > results as well, actually. I don't like using responders. > > > > > > > > Tracy > > > > > > > > ________________________________ > > > > From: [email protected] <mailto:flexcoders%40yahoogroups.com> > [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> > ] On > > Behalf Of Todd > > Sent: Thursday, October 16, 2008 12:37 PM > > To: [email protected] <mailto:flexcoders%40yahoogroups.com> > > Subject: [flexcoders] Re: WebService operation faults propigating up > to > > WebService fault handler. > > > > > > > > I'll bounce this back up as it's hard to find any source code samples > > using the Actionscript version of WebService, and properly handling > > all the different errors, etc... > > > > Thanks, > > > > --- In [email protected] > <mailto:flexcoders%40yahoogroups.com> > <mailto:flexcoders%40yahoogroups.com> > > , "Todd" <tprekaski@> wrote: > > > > > > Hello All, > > > I have a problem that I can't figure out. With WebService faults, > > > and operations that return SOAPFaults...read on for the detais. > > > > > > 1) I've created my WebService through ActionScript (not the MXML > > > Component). > > > var ws:WebService = new WebService(); > > > > > > 2) I've attached a fault listener to it. I had to do this because > > > it seems that SOAPEncoder errors were never being caught otherwise. > > > ws.addEventListener(FaultEvent.FAULT, onServiceFault) > > > > > > 3) I'm using a Cairngorm Command/ServiceDelegate calling scheme. > > > For example, to call getInvoices, I have a command that calls into > the > > > appropriate method on the ServiceDelegate called getInvoices, which > > > looks like: > > > public function getInvoices(params:Object):void{ > > > Operation(ws.SearchInvoices).encoder.strictNillability = true; > > > var token:AsyncToken = ws.SearchInvoices(params); > > > token.addResponder(this.responder); > > > } > > > > > > As you can see, I'm using the AsyncToken, and adding the Commmand as > > > the responder. The Command has both fault and result handlers as > > > defined by the IResponder interface. > > > > > > 4) The this.responder is set during the contstructor of the > > > Service Delegate, like so: > > > public function ServiceDelegate(responder:IResponder) > > > { > > > this.responder = responder; > > > } > > > > > > So, now my problem is, that when a SOAPFault is raised in the call > to > > > the SearchInvoices WebService operation, both the FAULT on my > Command > > > (which is the responder), AND the fault (onServiceFault ) for the > > > WebService definition. > > > > > > I'd really rather not have this happen, but can't really figure out > > > exactly what's going on. ALSO, I had to add the fault handler to the > > > WebService because we were having all sorts of SOAPEncoder errors > that > > > were never being raised. > > > > > > What's someone to do? Is it that since I'm using the AsyncResponder > > > to handle for the result/fault, that the WebService is never > notified > > > that the Fault has already been handled? What's the proper design > > > around this? Is there a way to set the status that the Fault's been > > > handled? It almost seems like the fault is being raised twice. > > > > > > Thanks, > > > Todd > > > > > >
