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>
>> 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
> Carlos Rovira