OK, more detail as promised.
So, good first try at a bead. Maybe we don't agree on the scenario. It
looked like this bead was considering a scenario where on one call, you
might set withCredentials=true, and on a subsequent call, you might set
withCredentials=false, in which case you don't want to remove the
listeners in postSend.
I was thinking of a much simpler scenario where you set withCredentials on
the XHR instance once and it stays unchanged. IMO, these two scenarios
makes a good case for beads. Before I saw your more elaborate version it
hadn't occurred to me that someone might want to make certain calls with
withCredentials being true sometimes and false other times. So, by
encapsulating this code in a bead, a simpler version can be used for the
"set it once" crowd, and this more elaborate version could be used by
someone who does want to change withCredentials in different calls.
It occurred to me only this morning that HTTPService is an ElementWrapper
and thus the beads can assume the element is created by the time the bead
is added.
Also, in most simple cases, the adding of the bead replaces the need for a
boolean property. IOW, if you don't need withCredentials set to true, you
don't add the bead and element.withCredentials remains at its default
false value.
So, the simplest version of this bead could look like this:
public function set strand(value:IStrand):void
{
((value as ElementWrapper).element as XHR).withCredentials = true;
}
No need for any event listeners or dispatching of preSend/postSend events.
But, you did point out that custom headers could also be implemented via a
bead. And a custom headers bead might need the preSend event as well.
And Om pointed out that other JS libraries provide interceptor functions
that are similar to a preSend event, so adding a "preSend" event seems
worth the cost. Other beads may leverage this, and thus you can't
attribute its cost to this particular CORS implementation.
And if you do move the custom headers code to a bead, then it will make
several of our examples smaller, so that's why I said that the final net
cost is <=0.
Regarding removing listeners, I just noticed that
ElementWrapper.removeBead does not set the beads strand to null. Right
now I think it should. What do others think? And then if you want to
worry about being removed you could check for null and remove listeners,
but IMO, there should be very few if any scenarios where beads get removed.
IMO, there is "application developer decision making" and "framework
developer decision making". When developing an application it is fine to
say "this is the way I need it to work" and not worry too much about
re-usability of code. But we really need the developers of the framework
to consider how other folks may need to use or extend the framework code
and provide events/hooks for that so the framework is "Flex-ible". So a
"preSend" event should be good. Is a "postSend" ever going to be needed?
Possibly, I haven't thought it through.
Finally, users of optional features will pay a higher cost than if we just
in-line everything. But then they can remove code from other options they
did not use. And, as I mentioned earlier, it is fine to produce a
separate component with everything baked in if it turns out that folks
need that kind of optimization. But realize that EVERY Flex app ever
built would be smaller and faster if if didn't use Flex. IMO, no
framework exists to make your code small and fast, it exists to improve
developer productivity. And while Flex made it really productive to build
the app, IMO, it failed for really big enterprise apps in the "last mile"
where all of that optional code did become a factor in size and
performance. There's a good chance that nobody on this mailing list ever
hit this problem because those that did probably aren't Flex customers any
more, but I saw it many times, from companies that have the potential to
hire many of us and drive the next generation of Flex. FlexJS is being
designed differently so that the "first mile" is as close to as fast as it
is in regular Flex, but also so that the "last mile" isn't where you run
out of resources. It does take a different mindset from regular Flex, but
I believe, and I think the rest of the PMC believes, that it is the right
direction for us to take.
My 2 cents,
-Alex
On 4/15/17, 10:53 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi,
>
>So just for giggles I implemented this as has recommended.
>
>The PAYG cost ends up being the following if you use it:
>- The loading cost for JS is an extra file in debug / 50+ lines of
>compiled code. Runtime cost in JS is two events dispatched and 50+ extra
>lines of code needed to be run.
>- 4 extra lines of code in AS version. The run time cost for AS is two
>events dispatched.
>
>The PAYG cost ends up being the following if you don’t use it for both AS
>and JS:
>- Two events dispatched and a couple of extra lines of code.
>
>If we were to go with my original function implementation the PAYG cost
>for AS is zero and the PAYG cost for JS is a 2 line function that is only
>used if called.
>
>There also seem a problem with JS only beads in that I couldn’t work out
>how to add it to the manifest as a JS only class. Anyone have any idea on
>how to do that? Adding it to NetworkClasses.as in a COMPILE::JS block
>didn’t work and caused complication errors.
>
>Thanks,
>Justin
