On 12/15/16, 12:33 PM, "Alex Harui" <[email protected]> wrote:
> > >On 12/15/16, 8:22 AM, "Peter Ent" <[email protected]> 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. Yes, that's true. Maybe in strandReady() you set a boolean like needsToWait which then triggers the BaseBead to set up the event listener. > >-Alex >
