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.
‹peter
On 12/15/16, 3:01 AM, "Yishay Weiss" <[email protected]> wrote:
>I see your point about overrides. It looks like set strand() is not the
>place to load partner beads. If that¹s the case, is it a bug that
>ContainerView.strand calls createViewport() which loads the model and the
>viewport?
>
>
>
>From: Alex Harui<mailto:[email protected]>
>Sent: Thursday, December 15, 2016 9:30 AM
>To: [email protected]<mailto:[email protected]>
>Subject: Re: [FlexJS] About Component Cycle and Events
>
>
>
>
>On 12/14/16, 10:25 PM, "Yishay Weiss" <[email protected]> wrote:
>>
>>That was my intent, load it when necessary. My point was that there was
>>no reason to attach event handlers when you need the bead, you can just
>>check for its existence and load it if necessary.
>
>I just took a look at strandutils. Sure it packages up a common pattern
>(check for bead, load bead from values manager), but I'm not understanding
>how it would work if called from within the strand setter. For example,
>if in MXML, someone did:
>
><SomeComponent>
> <beads>
> <SomeBead />
> <AnotherBeadThatWorksWIthSomeBead />
>
>I don't think SomeBead can use StrandUtils. The desired partner bead is
>about to be added to the strand right after SomeBead as an override for
>the default partner bead that would be fetched from ValuesManager. You
>could require that overrides have to be before the other partner bead, but
>some beads are peers and you can't really specify the order.
>
>I think that's why we recommend using an event. Once all beads are added,
>you get an event if you want it, and can get events when beads are added
>"later".
>
>-Alex
>
