Yes. We’re using XHR. I don’t understand the advantage of using
HTMLElementWrapper. I think all we need is a simple event dispatcher which
extending the Flex EventDispatcher seems to do.
As far as the events go, we’re handling the XHR events within the class and
dispatching separate generic events. There should be something to commit today
so you can see what I mean.
I saw BinaryUploader. I have a feeling that a URLLoader class might be able to
simplify both HTTPService and BinaryUploader. We can probably delegate all
platform-dependent code to a single place.
Why does HTTPService implement IStrand and IBead? Is that for data binding?
On Jul 4, 2016, at 8:30 AM, Alex Harui <aha...@adobe.com> wrote:
> Are you going to use XHR on the JS-side? HTMLElementWrapper has a good
> place to create the XHR and hooked some things in the JS event dispatching
> that you might also need.
>
> We also have a BinaryUploader that might be a good starting point.
>
> HTH,
> -Alex
>
> On 7/3/16, 10:02 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> For me the important piece is fetching and sending binary data and HTTP
>> codes. (I have a wrapper around it to handle errors, error codes,
>> multipart uploads, etc.)
>>
>> I have not studied the new HTTPService class very well, but the original
>> version was very rigid about the type of data it got.
>>
>> On Jul 4, 2016, at 7:53 AM, Alex Harui <aha...@adobe.com> wrote:
>>
>>> What does URLLoader do that HTTPService doesn't?
>>>
>>> -Alex
>>>
>>> On 7/3/16, 9:36 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>
>>>> Let me explain a bit better why I’m asking.
>>>>
>>>> Yishay and I are working on a URLLoader class which will behave similar
>>>> to the Flash URLLoader class. Is there any reason not to make both the
>>>> Flash and JS version extend EventDispatcher? From what I can see, the
>>>> flex EventDispatcher on the JS side extends goog.events.EventTarget. Is
>>>> there a concern with using that instead of HTMLElementWrapper (which
>>>> as I
>>>> understand it uses native DOM elements to dispatch events)?
>>>>
>>>> On Jul 3, 2016, at 5:52 PM, Alex Harui <aha...@adobe.com> wrote:
>>>>
>>>>>
>>>>>>
>>>>>> I’m not sure my question made sense, but I do have a related
>>>>>> question:
>>>>>> Why this?
>>>>>> COMPILE::SWF
>>>>>> public class HTTPServiceBase extends EventDispatcher
>>>>>> {
>>>>>> }
>>>>>>
>>>>>> COMPILE::JS
>>>>>> public class HTTPServiceBase extends HTMLElementWrapper
>>>>>> {
>>>>>> }
>>>>>>
>>>>>> Why is the JS side not extending EventDispatcher as well?
>>>>>
>>>>> IMO, some code somewhere as to abstract the platform differences and
>>>>> do
>>>>> it
>>>>> as thinly as possible for performance reasons, so the inheritance
>>>>> chain
>>>>> for classes don't have to be the same, the API surface they present
>>>>> does.
>>>>> I think there will be more emphasis on Interfaces like
>>>>> IEventDispatcher
>>>>> instead of base classes like EventDispatcher in FlexJS. It should
>>>>> keep
>>>>> us
>>>>> from wasting code trying to make everything look the same under the
>>>>> covers
>>>>> and prevent huge chains of class dependencies that make it hard to
>>>>> have
>>>>> separation of concerns and small applications.
>>>>>
>>>>> Or maybe I'm not understanding your question...
>>>>>
>>>>> -Alex
>>>>>
>>>>
>>>
>>
>
