If <js:beads> on a composed component can be appended by using the
component with its own beads, then you run the risk of duplicate beads
that might cause unpredictable results. A developer may not know what
beads a composed component might already have added to the strand.
We also have to then write beads to handle multiple "beadsAdded" events.
Right now, some beads wait for "beadsAdded" before creating the visual
elements or change the visual based on the beads added. Beads would have
to determine if they've already been down the beadsAdded path before and
decide to a) wipe out what they've done and do it over, b) ignore the new
event, c) blend new information into old, d) something else?
What happens if I make a component from Container and add in
HorizontalLayout and then someone uses my component but adds
VerticalLayout? Both layouts are then active and both beads will/may
receive the layoutNeeded event. I guess the developer that uses it will
see some sort of chaos happening and investigate, but this just leads to
longer development times to sort these things out.
I can offer no solution to this accept to say that appending the beads
would yield many more problems then replacing them. And if they are
replaced, I think we need an event ("beadsRemoved") be sent so that any
beads which might be active and consuming resources can close down
properly.
Peter Ent
Adobe Systems/Apache Flex Project
On 2/1/17, 10:56 AM, "Alex Harui" <aha...@adobe.com> wrote:
>
>
>On 2/1/17, 1:30 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
><carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com>
>wrote:
>
>>For me this is a missing feature that turns into a bug.
>>Maybe we could have two beads array. The actual could be the one uses
>>"static beads"
>>and other array used for developers to add and remove to avoid affect the
>>internal one
>
>Without looking into it, this sounds like a classic Flex problem. When
>you use an MXML file as the base class of another MXML file, and both
>specify values for an array property, what really should happen?
>
>An even more common problem is this:
>
><!-- Base.mxml -->
><s:Group>
> <s:Label id="lbl1" />
> <s:Label id="lbl2" />
></s:Group>
>
><!-- UseOfBase.mxml -->
><local:Base>
> <s:Label id="lbl3" />
></local:Base>
>
>Where should lbl3 go? Before or after lbl1 and lbl2? Or replace lbl1 and
>lbl2? I think the Flex MXMLC compiler results in replacement.
>
>That said, I tried to fix this for MXMLContent in Falcon/FalconJX. And I
>would have expected beads to append so IMO there is a bug in there,
>although before just fixing it, it would be good to understand the
>ramifications of such a fix.
>
>-Alex
>
