FlexJS Model beads

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FlexJS Model beads

Harbs
Studying the bead architecture it looks to me like IBeadModels should never attach event listeners.

(Strand allows for setting a new model and does not allow for cleaning up event listeners on the old model.)

Is that right?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS Model beads

Alex Harui-2
I would not expect a need to switch models at runtime, so clean up after
removal shouldn't be needed.  Honestly, I'd try to prevent any beads from
being swapped at runtime unless you are willing to pay for the cost.  I've
been thinking we should take out the removeBead API.  What kind of
scenario did you run into?

I can't immediately think of what a model needs to listen to, but maybe
there are scenarios I'm not thinking of.

My 2 cents,
-Alex

 

On 8/7/17, 11:00 AM, "Harbs" <[hidden email]> wrote:

>Studying the bead architecture it looks to me like IBeadModels should
>never attach event listeners.
>
>(Strand allows for setting a new model and does not allow for cleaning up
>event listeners on the old model.)
>
>Is that right?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS Model beads

Harbs
I’d be wary of taking out removeBead. The bead lifecycle is pretty basic, and I’m not sure PAYG should be applied to that.

I didn’t run into any scenario, I just noticed the following code in Strand.as:

public function set model(value:IBeadModel):void
{
        if (_model != value)
        {
                addBead(value as IBead);
                dispatchEvent(new Event("modelChanged"));
        }
}

and in addBead():

if (bead is IBeadModel)
        _model = bead as IBeadModel;

If for some reason two model beads are added, the second one will be the model, and the first one will just sit there (hopefully inactive).

I’m not sure if this is a problem.

> On Aug 7, 2017, at 9:55 PM, Alex Harui <[hidden email]> wrote:
>
> I would not expect a need to switch models at runtime, so clean up after
> removal shouldn't be needed.  Honestly, I'd try to prevent any beads from
> being swapped at runtime unless you are willing to pay for the cost.  I've
> been thinking we should take out the removeBead API.  What kind of
> scenario did you run into?
>
> I can't immediately think of what a model needs to listen to, but maybe
> there are scenarios I'm not thinking of.
>
> My 2 cents,
> -Alex
>
>
>
> On 8/7/17, 11:00 AM, "Harbs" <[hidden email]> wrote:
>
>> Studying the bead architecture it looks to me like IBeadModels should
>> never attach event listeners.
>>
>> (Strand allows for setting a new model and does not allow for cleaning up
>> event listeners on the old model.)
>>
>> Is that right?
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS Model beads

piotrz
In reply to this post by Alex Harui-2
Great subject.

 I think bead remove api can bring us more damage than benefits.

It won't be easy clean up some resources after remove. If we would like to use extensively we might need each time to do something with our class before removing. - It could be painful...

Piotr

Apache Flex PMC
piotrzarzycki21@gmail.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS Model beads

Alex Harui-2
In reply to this post by Harbs
If most apps are paying for removeBead just-in-case, we should take it.
Last time this topic came up my suggestion was to turn removeBead into a
utility function.  That way those who really do need it can pay for it.

The model setter probably could use some improvements.  It shouldn't need
change detection.  We should just find out who accidentally set the model
twice and fix that code.

Any time you add two beads of the same type, there is a chance for
confusion, so that should probably be avoided.

My 2 cents,
-Alex

On 8/7/17, 1:08 PM, "Harbs" <[hidden email]> wrote:

>I’d be wary of taking out removeBead. The bead lifecycle is pretty basic,
>and I’m not sure PAYG should be applied to that.
>
>I didn’t run into any scenario, I just noticed the following code in
>Strand.as:
>
>public function set model(value:IBeadModel):void
>{
> if (_model != value)
> {
> addBead(value as IBead);
> dispatchEvent(new Event("modelChanged"));
> }
>}
>
>and in addBead():
>
>if (bead is IBeadModel)
> _model = bead as IBeadModel;
>
>If for some reason two model beads are added, the second one will be the
>model, and the first one will just sit there (hopefully inactive).
>
>I’m not sure if this is a problem.
>
>> On Aug 7, 2017, at 9:55 PM, Alex Harui <[hidden email]> wrote:
>>
>> I would not expect a need to switch models at runtime, so clean up after
>> removal shouldn't be needed.  Honestly, I'd try to prevent any beads
>>from
>> being swapped at runtime unless you are willing to pay for the cost.
>>I've
>> been thinking we should take out the removeBead API.  What kind of
>> scenario did you run into?
>>
>> I can't immediately think of what a model needs to listen to, but maybe
>> there are scenarios I'm not thinking of.
>>
>> My 2 cents,
>> -Alex
>>
>>
>>
>> On 8/7/17, 11:00 AM, "Harbs" <[hidden email]> wrote:
>>
>>> Studying the bead architecture it looks to me like IBeadModels should
>>> never attach event listeners.
>>>
>>> (Strand allows for setting a new model and does not allow for cleaning
>>>up
>>> event listeners on the old model.)
>>>
>>> Is that right?
>>
>

Loading...