flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] About Component Cycle and Events
Date Thu, 15 Dec 2016 17:33:07 GMT


On 12/15/16, 8:22 AM, "Peter Ent" <pent@adobe.com> wrote:

>Having done a bunch of these, I'd like to propose something a little
>controversial. 
>
>A new class, BaseBead, from which all Beads derive (you can choose not to
>do this in your custom beads, just implement IBead). BaseBead has:
>
>public function set strand(value:IStrand):void {Š}
>public function get strand():IStrand {Š}
>
>public function strandReady():void
>- your bead class overrides strandReady() which is called by the strand
>setter function and in your override you set up your bead. If your bead
>needs to be aware of other beads, override the next function:
>
>public function beadsLoaded():void
>- your bead class, if it needs to, overrides beadsLoaded() and completes
>it set up. You can use strand.getBeadByType() to look for any other beads
>your bead might need.
>
>I separated the setting of the strand into two functions so that bead
>authors have a clear path in that they always override strandReady and
>optionally override beadsLoaded. This would give a consistent pattern to
>bead loading and allow the underlaying bead framework to be changed in the
>future. I don't think this will add much overhead to the PAYG plan, and I
>think it will be easier for developers to know what to do if there is a
>consistent set of steps to follow. These functions in BaseBead may be
>minor, but it would save developers from having to do the same thing over
>and over.

Hmm. Maybe.  How would the base class know when and whether to call
beadsLoaded.  Having every bead listen for beadsAdded might add up to
something.

-Alex

Mime
View raw message