Re: FlexJS Model beads

2017-08-07 Thread Alex Harui
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

Re: FlexJS Model beads

2017-08-07 Thread piotrz
pache Flex PMC piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/FlexJS-Model-beads-tp63725p63735.html Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS Model beads

2017-08-07 Thread 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) {

Re: FlexJS Model beads

2017-08-07 Thread Alex Harui
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 d

FlexJS Model beads

2017-08-07 Thread 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?