So you basically would like to in your code avoid changes FaultEvent to Event everywhere ? Yes ? That's the point in your case of having typed events for AMF handlers ?
2018-02-19 23:06 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>: > All AMF/RemoteObject API worked with that. And our AMF/RemoteObject > implementation in Royale does the same. In fact we already have FaultEvent > and Result Event... why don't use it? seems to me more complicated to > change it to no use that... > Our code relies heavily in AMF so all that classes are in lots of code to > manage the use of the incoming data for the server and that data is what > gives the result object from the backend to the client to manage it, > > 2018-02-19 23:00 GMT+01:00 Gabe Harbs <harbs.li...@gmail.com>: > >> I don’t use AMF, but I have no idea why you need specially typed events >> for that. >> >> Maybe I’m missing something… >> >> On Feb 19, 2018, at 11:38 PM, Carlos Rovira <carlosrov...@apache.org> >> wrote: >> >> Hi Harbs >> >> 2018-02-15 10:53 GMT+01:00 Gabe Harbs <harbs.li...@gmail.com>: >>> >>> None of the cases where I had ResultEvent and FaultEvent really made a >>> lot of sense to keep that logic in Royale (events should generally be of >>> type Event), so keeping those events would just mask places where code >>> should probably be rewritten. >>> >>> >> I think you was not using AMF. With RemoteObjects, I think Fault and >> Result events are a must or at least I can't imagine a way to handle the >> async behavior in other way. Maybe your scenario was different right? >> >> >> -- >> Carlos Rovira >> http://about.me/carlosrovira >> >> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
