You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2017/08/03 15:00:33 UTC
FlexJS Bead dilemma
I’m using a VerticalFlexLayout in a component. Under certain circumstances, I need to set the visibility of the component to false.
These two settings are contradictory in JS.
visible=false sets display to none
VerticalFlexLayout sets the display to flex
When setting visible to false, it uses a property “displayStyleForLayout” to store the value set by the layout. The problem is that the layout might be applied AFTER visible is already set to false (which is the case in my situation).
I’m thinking of solving this by exposing displayStyleForLayout so it can be set by beads if necessary.
Scratch that. I see that already exists. Problem solved… I’ll fix the layouts.
Harbs
Re: FlexJS Bead dilemma
Posted by Alex Harui <ah...@adobe.com.INVALID>.
OK. Well, IMO, the principle of composition, combined with the way we use
CSS "Type Selectors" means that the most explicit recommended practice is
to subclass to create a new type in order to get a new set of defaults to
compose. That's why there is an ImageButton instead of some other
mechanism to get a Button to handle images and why there will someday be a
MultipleSelectionList and other variants.
And then, if there are no currently existing beads that do what you want,
you compose a set of beads, in this case, LayoutOnShowBead and whatever
layout you want.
And then, if you want to optimize, you can always in-line or aggregate
beads into a single bead. So, you could aggregate LayoutOnShowBead with
the other layouts and create VerticalLayoutOnShow.
The above sequence is the recommended sequence for any new component
feature. Small pieces get composed, and in-lined when optimization is
needed. Any other mechanism that tries to inject a bead on the fly is
going to be more expensive and less efficient because it has to think
about injecting something just-in-case or will inject things everywhere
just-in-case. My wrapper idea would probably work, but is less efficient
than simply creating VerticalLayoutOnShow. Trying to get the compiler to
inject beads would also generate a lot of extra code. Someone may not
want the beads injected "everywhere" and then you end up with more
compiler options to try to control where the beads get injected. That's
why I think the compiler should not write code as much as check for errors
and encode the results.
However, we will probably want injection/swapping code for automated
testing, so getting started on that road by creating a bead or mixin that
can do that would be great to see as well.
Of course, I could be wrong...
-Alex
On 8/8/17, 1:03 AM, "Harbs" <ha...@gmail.com> wrote:
>None of this is really high priority for me right now.
>
>None of the layouts I’m using are really expensive layouts and any
>performance issues I’m having are caused by other problems.
>
>I’m more trying to figure out the best general resolution to this issue.
>
>Thanks,
>Harbs
>
>> On Aug 8, 2017, at 9:51 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> I don't know the details of your scenario. I was thinking that on the
>> first show event, the wrapper would remove the show event listener and
>> thus not install the actual layout bead more than once, but that may not
>> be what you want.
>>
>> I think your choices are:
>>
>> 1) Subclass Container and add a way to add the code to delay layout
>> 2) Inject the code you want via a central bead or mixin.
>> 3) Wrap as I've suggested here
>> 4) Wait for compiler changes that parse CSS and generate code, which is
>> not something I think we should do.
>>
>> There might be other ideas as well.
>>
>> HTH,
>> -Alex
>>
>> On 8/7/17, 11:35 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> If it doesn’t remove itself, it seems like you’d end up with two layout
>>> beads and it would probably keep injecting more layout beads each time
>>> the component is made visible.
>>>
>>>> On Aug 8, 2017, at 9:30 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>wrote:
>>>>
>>>> I was thinking the wrapper was an IBeadLayout, otherwise you couldn't
>>>> inject the wrapper via CSS without other changes. I'm not sure it has
>>>> to
>>>> remove itself before adding the actual bead or not. Somebody will
>>>>find
>>>> out if someone actually tries this.
>>>>
>>>> Other ideas are fine as well. I'm just pointing out options that
>>>>don't
>>>> require compiler or base class changes or just-in-case code. I'm not
>>>> sure
>>>> how you'd inject CheckForVisibleBeforeLayoutBead in every Container in
>>>> your app without doing the simple subclassing I suggested in the
>>>> beginning.
>>>>
>>>> -Alex
>>>>
>>>> On 8/7/17, 11:21 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>>>>
>>>>> But you would need to override all these calls (or remove the layout
>>>>> bead
>>>>> from CSS)
>>>>>
>>>>> addBead(new (ValuesManager.valuesImpl.getValue(this,
>>>>> "iBeadLayout")) as IBead);
>>>>>
>>>>> You wouldn’t need to if the wrapper was in itself an IBeadLayout, but
>>>>> then it would have to remove itself before adding its wrapped bead.
>>>>>
>>>>> To me it seems the main mode of communication between beads should be
>>>>> notifications. Another thing that might work here is to create a
>>>>> CheckForVisibleBeforeLayoutBead which would be added before the
>>>>>layout
>>>>> bead. It would listen on ‘layoutNeeded’ and
>>>>>stopImmediatePropagation()
>>>>> unless the host is visible.
>>>>>
>>>>> From: Alex Harui<ma...@adobe.com.INVALID>
>>>>> Sent: Tuesday, August 8, 2017 8:55 AM
>>>>> To: dev@flex.apache.org<ma...@flex.apache.org>
>>>>> Subject: Re: FlexJS Bead dilemma
>>>>>
>>>>> I was thinking the wrapper would just wait for the show event then
>>>>>set
>>>>> the
>>>>> strand on the actual layout bead. I'm not sure how much actually
>>>>>would
>>>>> need to be proxied or forwarded in that case. Or maybe the wrapper
>>>>> could
>>>>> just put the actual layout bead on the strand.
>>>>>
>>>>> Just tossing ideas around...
>>>>> -Alex
>>>>>
>>>>> On 8/7/17, 10:47 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>>>>>
>>>>>> That would make it a pretty thick wrapper. It would have to dispatch
>>>>>> all
>>>>>> the events that layout beads expect ,and implement ILayoutChild and
>>>>>> ILayoutParent. Have a look at LayoutBase to see the dependencies on
>>>>>> the
>>>>>> strand assumed by most layouts (and there are probably more in the
>>>>>> concrete classes).
>>>>>>
>>>>>>
>>>>>> Adding a meager LayoutOnShow bead seems cleaner to me.
>>>>>>
>>>>>> ________________________________
>>>>>> From: Alex Harui <ah...@adobe.com.INVALID>
>>>>>> Sent: Monday, August 7, 2017 6:58:29 PM
>>>>>> To: dev@flex.apache.org
>>>>>> Subject: Re: FlexJS Bead dilemma
>>>>>>
>>>>>> <SomeComponent>
>>>>>> <beads>
>>>>>> <LayoutOnlyWhenVisibleWrapperBead>
>>>>>> <VerticalLayout />
>>>>>> </LayoutOnlyWhenVisibleWrapperBead>
>>>>>> </beads>
>>>>>>
>>>>>> A bead could have a property which is another bead.
>>>>>>
>>>>>> Of course, I could be wrong...
>>>>>> -Alex
>>>>>>
>>>>>> On 8/7/17, 11:13 AM, "yishayw" <yi...@hotmail.com> wrote:
>>>>>>
>>>>>>> Alex Harui-2 wrote
>>>>>>>> A fancier alternative would be a bead that wraps a layout bead and
>>>>>>>> adds
>>>>>>>> the visible check. That might be the best way to apply PAYG.
>>>>>>>
>>>>>>> Can you explain what you mean? How would you wrap a bead?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>>
>>>>>>>
>>>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapac
>>>>>>>he
>>>>>>> -f
>>>>>>> l
>>>>>>> e
>>>>>>>
>>>>>>>
>>>>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Bead-dilemma-tp63681p63
>>>>>>>72
>>>>>>> 6.
>>>>>>> h
>>>>>>> t
>>>>>>>
>>>>>>>
>>>>>>>ml&data=02%7C01%7C%7C4491569503864889292108d4ddc03a7b%7Cfa7b1b5a7b34
>>>>>>>43
>>>>>>> 87
>>>>>>> 9
>>>>>>> 4
>>>>>>>
>>>>>>>
>>>>>>>aed2c178decee1%7C0%7C0%7C636377265065337580&sdata=XfcOsF4uBbpuF9DW2M
>>>>>>>t%
>>>>>>> 2F
>>>>>>> u
>>>>>>> 5
>>>>>>> zxSJYQth3mYyAwjLWJ88s%3D&reserved=0
>>>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>>>> Nabble.com.
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: FlexJS Bead dilemma
Posted by Harbs <ha...@gmail.com>.
None of this is really high priority for me right now.
None of the layouts I’m using are really expensive layouts and any performance issues I’m having are caused by other problems.
I’m more trying to figure out the best general resolution to this issue.
Thanks,
Harbs
> On Aug 8, 2017, at 9:51 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I don't know the details of your scenario. I was thinking that on the
> first show event, the wrapper would remove the show event listener and
> thus not install the actual layout bead more than once, but that may not
> be what you want.
>
> I think your choices are:
>
> 1) Subclass Container and add a way to add the code to delay layout
> 2) Inject the code you want via a central bead or mixin.
> 3) Wrap as I've suggested here
> 4) Wait for compiler changes that parse CSS and generate code, which is
> not something I think we should do.
>
> There might be other ideas as well.
>
> HTH,
> -Alex
>
> On 8/7/17, 11:35 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> If it doesn’t remove itself, it seems like you’d end up with two layout
>> beads and it would probably keep injecting more layout beads each time
>> the component is made visible.
>>
>>> On Aug 8, 2017, at 9:30 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> I was thinking the wrapper was an IBeadLayout, otherwise you couldn't
>>> inject the wrapper via CSS without other changes. I'm not sure it has
>>> to
>>> remove itself before adding the actual bead or not. Somebody will find
>>> out if someone actually tries this.
>>>
>>> Other ideas are fine as well. I'm just pointing out options that don't
>>> require compiler or base class changes or just-in-case code. I'm not
>>> sure
>>> how you'd inject CheckForVisibleBeforeLayoutBead in every Container in
>>> your app without doing the simple subclassing I suggested in the
>>> beginning.
>>>
>>> -Alex
>>>
>>> On 8/7/17, 11:21 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>>>
>>>> But you would need to override all these calls (or remove the layout
>>>> bead
>>>> from CSS)
>>>>
>>>> addBead(new (ValuesManager.valuesImpl.getValue(this,
>>>> "iBeadLayout")) as IBead);
>>>>
>>>> You wouldn’t need to if the wrapper was in itself an IBeadLayout, but
>>>> then it would have to remove itself before adding its wrapped bead.
>>>>
>>>> To me it seems the main mode of communication between beads should be
>>>> notifications. Another thing that might work here is to create a
>>>> CheckForVisibleBeforeLayoutBead which would be added before the layout
>>>> bead. It would listen on ‘layoutNeeded’ and stopImmediatePropagation()
>>>> unless the host is visible.
>>>>
>>>> From: Alex Harui<ma...@adobe.com.INVALID>
>>>> Sent: Tuesday, August 8, 2017 8:55 AM
>>>> To: dev@flex.apache.org<ma...@flex.apache.org>
>>>> Subject: Re: FlexJS Bead dilemma
>>>>
>>>> I was thinking the wrapper would just wait for the show event then set
>>>> the
>>>> strand on the actual layout bead. I'm not sure how much actually would
>>>> need to be proxied or forwarded in that case. Or maybe the wrapper
>>>> could
>>>> just put the actual layout bead on the strand.
>>>>
>>>> Just tossing ideas around...
>>>> -Alex
>>>>
>>>> On 8/7/17, 10:47 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>>>>
>>>>> That would make it a pretty thick wrapper. It would have to dispatch
>>>>> all
>>>>> the events that layout beads expect ,and implement ILayoutChild and
>>>>> ILayoutParent. Have a look at LayoutBase to see the dependencies on
>>>>> the
>>>>> strand assumed by most layouts (and there are probably more in the
>>>>> concrete classes).
>>>>>
>>>>>
>>>>> Adding a meager LayoutOnShow bead seems cleaner to me.
>>>>>
>>>>> ________________________________
>>>>> From: Alex Harui <ah...@adobe.com.INVALID>
>>>>> Sent: Monday, August 7, 2017 6:58:29 PM
>>>>> To: dev@flex.apache.org
>>>>> Subject: Re: FlexJS Bead dilemma
>>>>>
>>>>> <SomeComponent>
>>>>> <beads>
>>>>> <LayoutOnlyWhenVisibleWrapperBead>
>>>>> <VerticalLayout />
>>>>> </LayoutOnlyWhenVisibleWrapperBead>
>>>>> </beads>
>>>>>
>>>>> A bead could have a property which is another bead.
>>>>>
>>>>> Of course, I could be wrong...
>>>>> -Alex
>>>>>
>>>>> On 8/7/17, 11:13 AM, "yishayw" <yi...@hotmail.com> wrote:
>>>>>
>>>>>> Alex Harui-2 wrote
>>>>>>> A fancier alternative would be a bead that wraps a layout bead and
>>>>>>> adds
>>>>>>> the visible check. That might be the best way to apply PAYG.
>>>>>>
>>>>>> Can you explain what you mean? How would you wrap a bead?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache
>>>>>> -f
>>>>>> l
>>>>>> e
>>>>>>
>>>>>> x-development.2333347.n4.nabble.com%2FFlexJS-Bead-dilemma-tp63681p6372
>>>>>> 6.
>>>>>> h
>>>>>> t
>>>>>>
>>>>>> ml&data=02%7C01%7C%7C4491569503864889292108d4ddc03a7b%7Cfa7b1b5a7b3443
>>>>>> 87
>>>>>> 9
>>>>>> 4
>>>>>>
>>>>>> aed2c178decee1%7C0%7C0%7C636377265065337580&sdata=XfcOsF4uBbpuF9DW2Mt%
>>>>>> 2F
>>>>>> u
>>>>>> 5
>>>>>> zxSJYQth3mYyAwjLWJ88s%3D&reserved=0
>>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>>> Nabble.com.
>>>>>
>>>>
>>>
>>
>
Re: FlexJS Bead dilemma
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I don't know the details of your scenario. I was thinking that on the
first show event, the wrapper would remove the show event listener and
thus not install the actual layout bead more than once, but that may not
be what you want.
I think your choices are:
1) Subclass Container and add a way to add the code to delay layout
2) Inject the code you want via a central bead or mixin.
3) Wrap as I've suggested here
4) Wait for compiler changes that parse CSS and generate code, which is
not something I think we should do.
There might be other ideas as well.
HTH,
-Alex
On 8/7/17, 11:35 PM, "Harbs" <ha...@gmail.com> wrote:
>If it doesn’t remove itself, it seems like you’d end up with two layout
>beads and it would probably keep injecting more layout beads each time
>the component is made visible.
>
>> On Aug 8, 2017, at 9:30 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> I was thinking the wrapper was an IBeadLayout, otherwise you couldn't
>> inject the wrapper via CSS without other changes. I'm not sure it has
>>to
>> remove itself before adding the actual bead or not. Somebody will find
>> out if someone actually tries this.
>>
>> Other ideas are fine as well. I'm just pointing out options that don't
>> require compiler or base class changes or just-in-case code. I'm not
>>sure
>> how you'd inject CheckForVisibleBeforeLayoutBead in every Container in
>> your app without doing the simple subclassing I suggested in the
>>beginning.
>>
>> -Alex
>>
>> On 8/7/17, 11:21 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>>
>>> But you would need to override all these calls (or remove the layout
>>>bead
>>> from CSS)
>>>
>>> addBead(new (ValuesManager.valuesImpl.getValue(this,
>>> "iBeadLayout")) as IBead);
>>>
>>> You wouldn’t need to if the wrapper was in itself an IBeadLayout, but
>>> then it would have to remove itself before adding its wrapped bead.
>>>
>>> To me it seems the main mode of communication between beads should be
>>> notifications. Another thing that might work here is to create a
>>> CheckForVisibleBeforeLayoutBead which would be added before the layout
>>> bead. It would listen on ‘layoutNeeded’ and stopImmediatePropagation()
>>> unless the host is visible.
>>>
>>> From: Alex Harui<ma...@adobe.com.INVALID>
>>> Sent: Tuesday, August 8, 2017 8:55 AM
>>> To: dev@flex.apache.org<ma...@flex.apache.org>
>>> Subject: Re: FlexJS Bead dilemma
>>>
>>> I was thinking the wrapper would just wait for the show event then set
>>>the
>>> strand on the actual layout bead. I'm not sure how much actually would
>>> need to be proxied or forwarded in that case. Or maybe the wrapper
>>>could
>>> just put the actual layout bead on the strand.
>>>
>>> Just tossing ideas around...
>>> -Alex
>>>
>>> On 8/7/17, 10:47 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>>>
>>>> That would make it a pretty thick wrapper. It would have to dispatch
>>>>all
>>>> the events that layout beads expect ,and implement ILayoutChild and
>>>> ILayoutParent. Have a look at LayoutBase to see the dependencies on
>>>>the
>>>> strand assumed by most layouts (and there are probably more in the
>>>> concrete classes).
>>>>
>>>>
>>>> Adding a meager LayoutOnShow bead seems cleaner to me.
>>>>
>>>> ________________________________
>>>> From: Alex Harui <ah...@adobe.com.INVALID>
>>>> Sent: Monday, August 7, 2017 6:58:29 PM
>>>> To: dev@flex.apache.org
>>>> Subject: Re: FlexJS Bead dilemma
>>>>
>>>> <SomeComponent>
>>>> <beads>
>>>> <LayoutOnlyWhenVisibleWrapperBead>
>>>> <VerticalLayout />
>>>> </LayoutOnlyWhenVisibleWrapperBead>
>>>> </beads>
>>>>
>>>> A bead could have a property which is another bead.
>>>>
>>>> Of course, I could be wrong...
>>>> -Alex
>>>>
>>>> On 8/7/17, 11:13 AM, "yishayw" <yi...@hotmail.com> wrote:
>>>>
>>>>> Alex Harui-2 wrote
>>>>>> A fancier alternative would be a bead that wraps a layout bead and
>>>>>> adds
>>>>>> the visible check. That might be the best way to apply PAYG.
>>>>>
>>>>> Can you explain what you mean? How would you wrap a bead?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache
>>>>>-f
>>>>> l
>>>>> e
>>>>>
>>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Bead-dilemma-tp63681p6372
>>>>>6.
>>>>> h
>>>>> t
>>>>>
>>>>>ml&data=02%7C01%7C%7C4491569503864889292108d4ddc03a7b%7Cfa7b1b5a7b3443
>>>>>87
>>>>> 9
>>>>> 4
>>>>>
>>>>>aed2c178decee1%7C0%7C0%7C636377265065337580&sdata=XfcOsF4uBbpuF9DW2Mt%
>>>>>2F
>>>>> u
>>>>> 5
>>>>> zxSJYQth3mYyAwjLWJ88s%3D&reserved=0
>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>> Nabble.com.
>>>>
>>>
>>
>
Re: FlexJS Bead dilemma
Posted by Harbs <ha...@gmail.com>.
If it doesn’t remove itself, it seems like you’d end up with two layout beads and it would probably keep injecting more layout beads each time the component is made visible.
> On Aug 8, 2017, at 9:30 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I was thinking the wrapper was an IBeadLayout, otherwise you couldn't
> inject the wrapper via CSS without other changes. I'm not sure it has to
> remove itself before adding the actual bead or not. Somebody will find
> out if someone actually tries this.
>
> Other ideas are fine as well. I'm just pointing out options that don't
> require compiler or base class changes or just-in-case code. I'm not sure
> how you'd inject CheckForVisibleBeforeLayoutBead in every Container in
> your app without doing the simple subclassing I suggested in the beginning.
>
> -Alex
>
> On 8/7/17, 11:21 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>
>> But you would need to override all these calls (or remove the layout bead
>> from CSS)
>>
>> addBead(new (ValuesManager.valuesImpl.getValue(this,
>> "iBeadLayout")) as IBead);
>>
>> You wouldn’t need to if the wrapper was in itself an IBeadLayout, but
>> then it would have to remove itself before adding its wrapped bead.
>>
>> To me it seems the main mode of communication between beads should be
>> notifications. Another thing that might work here is to create a
>> CheckForVisibleBeforeLayoutBead which would be added before the layout
>> bead. It would listen on ‘layoutNeeded’ and stopImmediatePropagation()
>> unless the host is visible.
>>
>> From: Alex Harui<ma...@adobe.com.INVALID>
>> Sent: Tuesday, August 8, 2017 8:55 AM
>> To: dev@flex.apache.org<ma...@flex.apache.org>
>> Subject: Re: FlexJS Bead dilemma
>>
>> I was thinking the wrapper would just wait for the show event then set the
>> strand on the actual layout bead. I'm not sure how much actually would
>> need to be proxied or forwarded in that case. Or maybe the wrapper could
>> just put the actual layout bead on the strand.
>>
>> Just tossing ideas around...
>> -Alex
>>
>> On 8/7/17, 10:47 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>>
>>> That would make it a pretty thick wrapper. It would have to dispatch all
>>> the events that layout beads expect ,and implement ILayoutChild and
>>> ILayoutParent. Have a look at LayoutBase to see the dependencies on the
>>> strand assumed by most layouts (and there are probably more in the
>>> concrete classes).
>>>
>>>
>>> Adding a meager LayoutOnShow bead seems cleaner to me.
>>>
>>> ________________________________
>>> From: Alex Harui <ah...@adobe.com.INVALID>
>>> Sent: Monday, August 7, 2017 6:58:29 PM
>>> To: dev@flex.apache.org
>>> Subject: Re: FlexJS Bead dilemma
>>>
>>> <SomeComponent>
>>> <beads>
>>> <LayoutOnlyWhenVisibleWrapperBead>
>>> <VerticalLayout />
>>> </LayoutOnlyWhenVisibleWrapperBead>
>>> </beads>
>>>
>>> A bead could have a property which is another bead.
>>>
>>> Of course, I could be wrong...
>>> -Alex
>>>
>>> On 8/7/17, 11:13 AM, "yishayw" <yi...@hotmail.com> wrote:
>>>
>>>> Alex Harui-2 wrote
>>>>> A fancier alternative would be a bead that wraps a layout bead and
>>>>> adds
>>>>> the visible check. That might be the best way to apply PAYG.
>>>>
>>>> Can you explain what you mean? How would you wrap a bead?
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>> l
>>>> e
>>>> x-development.2333347.n4.nabble.com%2FFlexJS-Bead-dilemma-tp63681p63726.
>>>> h
>>>> t
>>>> ml&data=02%7C01%7C%7C4491569503864889292108d4ddc03a7b%7Cfa7b1b5a7b344387
>>>> 9
>>>> 4
>>>> aed2c178decee1%7C0%7C0%7C636377265065337580&sdata=XfcOsF4uBbpuF9DW2Mt%2F
>>>> u
>>>> 5
>>>> zxSJYQth3mYyAwjLWJ88s%3D&reserved=0
>>>> Sent from the Apache Flex Development mailing list archive at
>>>> Nabble.com.
>>>
>>
>
Re: FlexJS Bead dilemma
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I was thinking the wrapper was an IBeadLayout, otherwise you couldn't
inject the wrapper via CSS without other changes. I'm not sure it has to
remove itself before adding the actual bead or not. Somebody will find
out if someone actually tries this.
Other ideas are fine as well. I'm just pointing out options that don't
require compiler or base class changes or just-in-case code. I'm not sure
how you'd inject CheckForVisibleBeforeLayoutBead in every Container in
your app without doing the simple subclassing I suggested in the beginning.
-Alex
On 8/7/17, 11:21 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>But you would need to override all these calls (or remove the layout bead
>from CSS)
>
> addBead(new (ValuesManager.valuesImpl.getValue(this,
>"iBeadLayout")) as IBead);
>
>You wouldn’t need to if the wrapper was in itself an IBeadLayout, but
>then it would have to remove itself before adding its wrapped bead.
>
>To me it seems the main mode of communication between beads should be
>notifications. Another thing that might work here is to create a
>CheckForVisibleBeforeLayoutBead which would be added before the layout
>bead. It would listen on ‘layoutNeeded’ and stopImmediatePropagation()
>unless the host is visible.
>
>From: Alex Harui<ma...@adobe.com.INVALID>
>Sent: Tuesday, August 8, 2017 8:55 AM
>To: dev@flex.apache.org<ma...@flex.apache.org>
>Subject: Re: FlexJS Bead dilemma
>
>I was thinking the wrapper would just wait for the show event then set the
>strand on the actual layout bead. I'm not sure how much actually would
>need to be proxied or forwarded in that case. Or maybe the wrapper could
>just put the actual layout bead on the strand.
>
>Just tossing ideas around...
>-Alex
>
>On 8/7/17, 10:47 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>
>>That would make it a pretty thick wrapper. It would have to dispatch all
>>the events that layout beads expect ,and implement ILayoutChild and
>>ILayoutParent. Have a look at LayoutBase to see the dependencies on the
>>strand assumed by most layouts (and there are probably more in the
>>concrete classes).
>>
>>
>>Adding a meager LayoutOnShow bead seems cleaner to me.
>>
>>________________________________
>>From: Alex Harui <ah...@adobe.com.INVALID>
>>Sent: Monday, August 7, 2017 6:58:29 PM
>>To: dev@flex.apache.org
>>Subject: Re: FlexJS Bead dilemma
>>
>><SomeComponent>
>> <beads>
>> <LayoutOnlyWhenVisibleWrapperBead>
>> <VerticalLayout />
>> </LayoutOnlyWhenVisibleWrapperBead>
>> </beads>
>>
>>A bead could have a property which is another bead.
>>
>>Of course, I could be wrong...
>>-Alex
>>
>>On 8/7/17, 11:13 AM, "yishayw" <yi...@hotmail.com> wrote:
>>
>>>Alex Harui-2 wrote
>>>> A fancier alternative would be a bead that wraps a layout bead and
>>>>adds
>>>> the visible check. That might be the best way to apply PAYG.
>>>
>>>Can you explain what you mean? How would you wrap a bead?
>>>
>>>
>>>
>>>
>>>--
>>>View this message in context:
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>l
>>>e
>>>x-development.2333347.n4.nabble.com%2FFlexJS-Bead-dilemma-tp63681p63726.
>>>h
>>>t
>>>ml&data=02%7C01%7C%7C4491569503864889292108d4ddc03a7b%7Cfa7b1b5a7b344387
>>>9
>>>4
>>>aed2c178decee1%7C0%7C0%7C636377265065337580&sdata=XfcOsF4uBbpuF9DW2Mt%2F
>>>u
>>>5
>>>zxSJYQth3mYyAwjLWJ88s%3D&reserved=0
>>>Sent from the Apache Flex Development mailing list archive at
>>>Nabble.com.
>>
>
RE: FlexJS Bead dilemma
Posted by Yishay Weiss <yi...@hotmail.com>.
But you would need to override all these calls (or remove the layout bead from CSS)
addBead(new (ValuesManager.valuesImpl.getValue(this, "iBeadLayout")) as IBead);
You wouldn’t need to if the wrapper was in itself an IBeadLayout, but then it would have to remove itself before adding its wrapped bead.
To me it seems the main mode of communication between beads should be notifications. Another thing that might work here is to create a CheckForVisibleBeforeLayoutBead which would be added before the layout bead. It would listen on ‘layoutNeeded’ and stopImmediatePropagation() unless the host is visible.
From: Alex Harui<ma...@adobe.com.INVALID>
Sent: Tuesday, August 8, 2017 8:55 AM
To: dev@flex.apache.org<ma...@flex.apache.org>
Subject: Re: FlexJS Bead dilemma
I was thinking the wrapper would just wait for the show event then set the
strand on the actual layout bead. I'm not sure how much actually would
need to be proxied or forwarded in that case. Or maybe the wrapper could
just put the actual layout bead on the strand.
Just tossing ideas around...
-Alex
On 8/7/17, 10:47 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>That would make it a pretty thick wrapper. It would have to dispatch all
>the events that layout beads expect ,and implement ILayoutChild and
>ILayoutParent. Have a look at LayoutBase to see the dependencies on the
>strand assumed by most layouts (and there are probably more in the
>concrete classes).
>
>
>Adding a meager LayoutOnShow bead seems cleaner to me.
>
>________________________________
>From: Alex Harui <ah...@adobe.com.INVALID>
>Sent: Monday, August 7, 2017 6:58:29 PM
>To: dev@flex.apache.org
>Subject: Re: FlexJS Bead dilemma
>
><SomeComponent>
> <beads>
> <LayoutOnlyWhenVisibleWrapperBead>
> <VerticalLayout />
> </LayoutOnlyWhenVisibleWrapperBead>
> </beads>
>
>A bead could have a property which is another bead.
>
>Of course, I could be wrong...
>-Alex
>
>On 8/7/17, 11:13 AM, "yishayw" <yi...@hotmail.com> wrote:
>
>>Alex Harui-2 wrote
>>> A fancier alternative would be a bead that wraps a layout bead and adds
>>> the visible check. That might be the best way to apply PAYG.
>>
>>Can you explain what you mean? How would you wrap a bead?
>>
>>
>>
>>
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.2333347.n4.nabble.com%2FFlexJS-Bead-dilemma-tp63681p63726.h
>>t
>>ml&data=02%7C01%7C%7C4491569503864889292108d4ddc03a7b%7Cfa7b1b5a7b3443879
>>4
>>aed2c178decee1%7C0%7C0%7C636377265065337580&sdata=XfcOsF4uBbpuF9DW2Mt%2Fu
>>5
>>zxSJYQth3mYyAwjLWJ88s%3D&reserved=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: FlexJS Bead dilemma
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I was thinking the wrapper would just wait for the show event then set the
strand on the actual layout bead. I'm not sure how much actually would
need to be proxied or forwarded in that case. Or maybe the wrapper could
just put the actual layout bead on the strand.
Just tossing ideas around...
-Alex
On 8/7/17, 10:47 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>That would make it a pretty thick wrapper. It would have to dispatch all
>the events that layout beads expect ,and implement ILayoutChild and
>ILayoutParent. Have a look at LayoutBase to see the dependencies on the
>strand assumed by most layouts (and there are probably more in the
>concrete classes).
>
>
>Adding a meager LayoutOnShow bead seems cleaner to me.
>
>________________________________
>From: Alex Harui <ah...@adobe.com.INVALID>
>Sent: Monday, August 7, 2017 6:58:29 PM
>To: dev@flex.apache.org
>Subject: Re: FlexJS Bead dilemma
>
><SomeComponent>
> <beads>
> <LayoutOnlyWhenVisibleWrapperBead>
> <VerticalLayout />
> </LayoutOnlyWhenVisibleWrapperBead>
> </beads>
>
>A bead could have a property which is another bead.
>
>Of course, I could be wrong...
>-Alex
>
>On 8/7/17, 11:13 AM, "yishayw" <yi...@hotmail.com> wrote:
>
>>Alex Harui-2 wrote
>>> A fancier alternative would be a bead that wraps a layout bead and adds
>>> the visible check. That might be the best way to apply PAYG.
>>
>>Can you explain what you mean? How would you wrap a bead?
>>
>>
>>
>>
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.2333347.n4.nabble.com%2FFlexJS-Bead-dilemma-tp63681p63726.h
>>t
>>ml&data=02%7C01%7C%7C4491569503864889292108d4ddc03a7b%7Cfa7b1b5a7b3443879
>>4
>>aed2c178decee1%7C0%7C0%7C636377265065337580&sdata=XfcOsF4uBbpuF9DW2Mt%2Fu
>>5
>>zxSJYQth3mYyAwjLWJ88s%3D&reserved=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: FlexJS Bead dilemma
Posted by Yishay Weiss <yi...@hotmail.com>.
That would make it a pretty thick wrapper. It would have to dispatch all the events that layout beads expect ,and implement ILayoutChild and ILayoutParent. Have a look at LayoutBase to see the dependencies on the strand assumed by most layouts (and there are probably more in the concrete classes).
Adding a meager LayoutOnShow bead seems cleaner to me.
________________________________
From: Alex Harui <ah...@adobe.com.INVALID>
Sent: Monday, August 7, 2017 6:58:29 PM
To: dev@flex.apache.org
Subject: Re: FlexJS Bead dilemma
<SomeComponent>
<beads>
<LayoutOnlyWhenVisibleWrapperBead>
<VerticalLayout />
</LayoutOnlyWhenVisibleWrapperBead>
</beads>
A bead could have a property which is another bead.
Of course, I could be wrong...
-Alex
On 8/7/17, 11:13 AM, "yishayw" <yi...@hotmail.com> wrote:
>Alex Harui-2 wrote
>> A fancier alternative would be a bead that wraps a layout bead and adds
>> the visible check. That might be the best way to apply PAYG.
>
>Can you explain what you mean? How would you wrap a bead?
>
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-Bead-dilemma-tp63681p63726.ht
>ml&data=02%7C01%7C%7C4491569503864889292108d4ddc03a7b%7Cfa7b1b5a7b34438794
>aed2c178decee1%7C0%7C0%7C636377265065337580&sdata=XfcOsF4uBbpuF9DW2Mt%2Fu5
>zxSJYQth3mYyAwjLWJ88s%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS Bead dilemma
Posted by Alex Harui <ah...@adobe.com.INVALID>.
<SomeComponent>
<beads>
<LayoutOnlyWhenVisibleWrapperBead>
<VerticalLayout />
</LayoutOnlyWhenVisibleWrapperBead>
</beads>
A bead could have a property which is another bead.
Of course, I could be wrong...
-Alex
On 8/7/17, 11:13 AM, "yishayw" <yi...@hotmail.com> wrote:
>Alex Harui-2 wrote
>> A fancier alternative would be a bead that wraps a layout bead and adds
>> the visible check. That might be the best way to apply PAYG.
>
>Can you explain what you mean? How would you wrap a bead?
>
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-Bead-dilemma-tp63681p63726.ht
>ml&data=02%7C01%7C%7C4491569503864889292108d4ddc03a7b%7Cfa7b1b5a7b34438794
>aed2c178decee1%7C0%7C0%7C636377265065337580&sdata=XfcOsF4uBbpuF9DW2Mt%2Fu5
>zxSJYQth3mYyAwjLWJ88s%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS Bead dilemma
Posted by yishayw <yi...@hotmail.com>.
Alex Harui-2 wrote
> A fancier alternative would be a bead that wraps a layout bead and adds
> the visible check. That might be the best way to apply PAYG.
Can you explain what you mean? How would you wrap a bead?
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Bead-dilemma-tp63681p63726.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS Bead dilemma
Posted by Alex Harui <ah...@adobe.com.INVALID>.
The problem with even the simple check for visible is that it will run for
every container, but you might have dozens of containers that are never
ever made invisible.
A brute force alternative is different set of layouts that check for
visible.
A fancier alternative would be a bead that wraps a layout bead and adds
the visible check. That might be the best way to apply PAYG.
Thoughts?
-Alex
On 8/6/17, 10:18 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>
>
>
>
>>The bead is probably more PAYG, but it’s also more “pay” when you do go.
>>Changing bead >notifications would probably make it cheaper though.
>
>That’s a major point in my opinion. If we knew the cost of dispatching a
>notification was next to nothing we would be able to provide lots of
>hooks, and PAYG would become much simpler. A heavy notification sort of
>beats the purpose because of the performance overhead.
>
>>unnecessary layouts), but not do #2. The question I have is whether to
>>add the LayoutOnShow >bead to the defaults for Basic, or should that
>>only go into Express?
>
>I would add it to express. There might be basic apps without any
>invisible components.
>
>
>
>>Harbs
>
>> On Aug 3, 2017, at 11:57 PM, Harbs <ha...@gmail.com> wrote:
>>
>> My ideas on bead lifecycles might help for this. Not sure.
>>
>> I’m not sure there’s a perfect solution to this problem.
>>
>> If I have to weigh a single check for visible vs an entire layout, I’d
>>go for the former.
>>
>> I seem to recall that we did something to prevent non-visible
>>components for going throw layout, but I don’t remember any details.
>>Maybe Yishay knows what I’m talking about.
>>
>>> On Aug 3, 2017, at 7:18 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>wrote:
>>>
>>> Yeah, but I also remembered on other thing. The vast majority of
>>> components are never made invisible, so adding a check in each layout
>>>bead
>>> just-in-case they are made invisible isn't very PAYG.
>>>
>>> So maybe there is some other way that setting visible=false can inject
>>> code that handles sharing the CSS display property with the layouts.
>>>Or
>>> maybe it isn't worth worrying about right now.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>> On 8/3/17, 8:50 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> But it it doesn’t set display, we’re going to have to run layout every
>>>> time the visibility changes.
>>>>
>>>> I’ve already made my changes. I’ll commit soon.
>>>>
>>>> Ah. I see what you mean. By doing it your way, there’s no reason to
>>>> actually run layout until (or if) the visibility is set to true.
>>>>
>>>> That probably *is* better. I’ll commit what I did for now, because it
>>>>at
>>>> least fixes the bug, and when I have time, I’ll look into improving
>>>>the
>>>> layouts.
>>>>
>>>> Another thought:
>>>>
>>>> If visibility is turned on and off multiple times, this might be less
>>>> efficient, but the layout might be able to store a flag to avoid
>>>>running
>>>> the layout if not needed…
>>>>
>>>> Harbs
>>>>
>>>>> On Aug 3, 2017, at 6:24 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>wrote:
>>>>>
>>>>> Right, so layout code would have to check for display=="none" and not
>>>>> set
>>>>> display and listen for the show event.
>>>>>
>>>>> Maybe as you clean up the setting of display multiple times it will
>>>>>be
>>>>> come clear as to whether listening for "show" is cheaper/cleaner than
>>>>> displayStyleForLayout.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 8/3/17, 8:18 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> The problem is that visible is set before the bead exists.
>>>>>>
>>>>>> BTW, Some of the layout seem to be reading and setting display
>>>>>>multiple
>>>>>> times. That can cause layout thrashing. That should probably be
>>>>>> resolved.
>>>>>>
>>>>>>> On Aug 3, 2017, at 6:05 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>>> wrote:
>>>>>>>
>>>>>>> FWIW, I'm not sure this is the best pattern. It was what we did to
>>>>>>> get
>>>>>>> the examples to run.
>>>>>>>
>>>>>>> Another option is that layout beads listen for changes to visible
>>>>>>>and
>>>>>>> reset the CSS display style when visible changes.
>>>>>>>
>>>>>>> Food for thought,
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 8/3/17, 8:00 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>
>>>>>>>> I’m using a VerticalFlexLayout in a component. Under certain
>>>>>>>> circumstances, I need to set the visibility of the component to
>>>>>>>> false.
>>>>>>>>
>>>>>>>> These two settings are contradictory in JS.
>>>>>>>>
>>>>>>>> visible=false sets display to none
>>>>>>>> VerticalFlexLayout sets the display to flex
>>>>>>>>
>>>>>>>> When setting visible to false, it uses a property
>>>>>>>> “displayStyleForLayout”
>>>>>>>> to store the value set by the layout. The problem is that the
>>>>>>>>layout
>>>>>>>> might be applied AFTER visible is already set to false (which is
>>>>>>>>the
>>>>>>>> case
>>>>>>>> in my situation).
>>>>>>>>
>>>>>>>> I’m thinking of solving this by exposing displayStyleForLayout so
>>>>>>>>it
>>>>>>>> can
>>>>>>>> be set by beads if necessary.
>>>>>>>>
>>>>>>>> Scratch that. I see that already exists. Problem solved… I’ll fix
>>>>>>>>the
>>>>>>>> layouts.
>>>>>>>>
>>>>>>>> Harbs
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
RE: FlexJS Bead dilemma
Posted by Yishay Weiss <yi...@hotmail.com>.
>The bead is probably more PAYG, but it’s also more “pay” when you do go. Changing bead >notifications would probably make it cheaper though.
That’s a major point in my opinion. If we knew the cost of dispatching a notification was next to nothing we would be able to provide lots of hooks, and PAYG would become much simpler. A heavy notification sort of beats the purpose because of the performance overhead.
>unnecessary layouts), but not do #2. The question I have is whether to add the LayoutOnShow >bead to the defaults for Basic, or should that only go into Express?
I would add it to express. There might be basic apps without any invisible components.
>Harbs
> On Aug 3, 2017, at 11:57 PM, Harbs <ha...@gmail.com> wrote:
>
> My ideas on bead lifecycles might help for this. Not sure.
>
> I’m not sure there’s a perfect solution to this problem.
>
> If I have to weigh a single check for visible vs an entire layout, I’d go for the former.
>
> I seem to recall that we did something to prevent non-visible components for going throw layout, but I don’t remember any details. Maybe Yishay knows what I’m talking about.
>
>> On Aug 3, 2017, at 7:18 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Yeah, but I also remembered on other thing. The vast majority of
>> components are never made invisible, so adding a check in each layout bead
>> just-in-case they are made invisible isn't very PAYG.
>>
>> So maybe there is some other way that setting visible=false can inject
>> code that handles sharing the CSS display property with the layouts. Or
>> maybe it isn't worth worrying about right now.
>>
>> My 2 cents,
>> -Alex
>>
>> On 8/3/17, 8:50 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> But it it doesn’t set display, we’re going to have to run layout every
>>> time the visibility changes.
>>>
>>> I’ve already made my changes. I’ll commit soon.
>>>
>>> Ah. I see what you mean. By doing it your way, there’s no reason to
>>> actually run layout until (or if) the visibility is set to true.
>>>
>>> That probably *is* better. I’ll commit what I did for now, because it at
>>> least fixes the bug, and when I have time, I’ll look into improving the
>>> layouts.
>>>
>>> Another thought:
>>>
>>> If visibility is turned on and off multiple times, this might be less
>>> efficient, but the layout might be able to store a flag to avoid running
>>> the layout if not needed…
>>>
>>> Harbs
>>>
>>>> On Aug 3, 2017, at 6:24 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>
>>>> Right, so layout code would have to check for display=="none" and not
>>>> set
>>>> display and listen for the show event.
>>>>
>>>> Maybe as you clean up the setting of display multiple times it will be
>>>> come clear as to whether listening for "show" is cheaper/cleaner than
>>>> displayStyleForLayout.
>>>>
>>>> -Alex
>>>>
>>>> On 8/3/17, 8:18 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> The problem is that visible is set before the bead exists.
>>>>>
>>>>> BTW, Some of the layout seem to be reading and setting display multiple
>>>>> times. That can cause layout thrashing. That should probably be
>>>>> resolved.
>>>>>
>>>>>> On Aug 3, 2017, at 6:05 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>> wrote:
>>>>>>
>>>>>> FWIW, I'm not sure this is the best pattern. It was what we did to
>>>>>> get
>>>>>> the examples to run.
>>>>>>
>>>>>> Another option is that layout beads listen for changes to visible and
>>>>>> reset the CSS display style when visible changes.
>>>>>>
>>>>>> Food for thought,
>>>>>> -Alex
>>>>>>
>>>>>> On 8/3/17, 8:00 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>
>>>>>>> I’m using a VerticalFlexLayout in a component. Under certain
>>>>>>> circumstances, I need to set the visibility of the component to
>>>>>>> false.
>>>>>>>
>>>>>>> These two settings are contradictory in JS.
>>>>>>>
>>>>>>> visible=false sets display to none
>>>>>>> VerticalFlexLayout sets the display to flex
>>>>>>>
>>>>>>> When setting visible to false, it uses a property
>>>>>>> “displayStyleForLayout”
>>>>>>> to store the value set by the layout. The problem is that the layout
>>>>>>> might be applied AFTER visible is already set to false (which is the
>>>>>>> case
>>>>>>> in my situation).
>>>>>>>
>>>>>>> I’m thinking of solving this by exposing displayStyleForLayout so it
>>>>>>> can
>>>>>>> be set by beads if necessary.
>>>>>>>
>>>>>>> Scratch that. I see that already exists. Problem solved… I’ll fix the
>>>>>>> layouts.
>>>>>>>
>>>>>>> Harbs
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: FlexJS Bead dilemma
Posted by Harbs <ha...@gmail.com>.
I started on this. I was doing two things:
1. I added a visible check to only trigger layout if visible is true. There are very few places this is needed. It’s not a lot of extra code.
2. I started adding “show” event listeners. During the process I noticed there is already a “LayoutOnShow” bead which injects a “show” event listener which in turn dispatches a layoutNeeded event.
The bead is probably more PAYG, but it’s also more “pay” when you do go. Changing bead notifications would probably make it cheaper though.
So, I’m going to keep #1 (because I don’t see any other straight-forward way of avoiding the unnecessary layouts), but not do #2. The question I have is whether to add the LayoutOnShow bead to the defaults for Basic, or should that only go into Express?
Harbs
> On Aug 3, 2017, at 11:57 PM, Harbs <ha...@gmail.com> wrote:
>
> My ideas on bead lifecycles might help for this. Not sure.
>
> I’m not sure there’s a perfect solution to this problem.
>
> If I have to weigh a single check for visible vs an entire layout, I’d go for the former.
>
> I seem to recall that we did something to prevent non-visible components for going throw layout, but I don’t remember any details. Maybe Yishay knows what I’m talking about.
>
>> On Aug 3, 2017, at 7:18 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Yeah, but I also remembered on other thing. The vast majority of
>> components are never made invisible, so adding a check in each layout bead
>> just-in-case they are made invisible isn't very PAYG.
>>
>> So maybe there is some other way that setting visible=false can inject
>> code that handles sharing the CSS display property with the layouts. Or
>> maybe it isn't worth worrying about right now.
>>
>> My 2 cents,
>> -Alex
>>
>> On 8/3/17, 8:50 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> But it it doesn’t set display, we’re going to have to run layout every
>>> time the visibility changes.
>>>
>>> I’ve already made my changes. I’ll commit soon.
>>>
>>> Ah. I see what you mean. By doing it your way, there’s no reason to
>>> actually run layout until (or if) the visibility is set to true.
>>>
>>> That probably *is* better. I’ll commit what I did for now, because it at
>>> least fixes the bug, and when I have time, I’ll look into improving the
>>> layouts.
>>>
>>> Another thought:
>>>
>>> If visibility is turned on and off multiple times, this might be less
>>> efficient, but the layout might be able to store a flag to avoid running
>>> the layout if not needed…
>>>
>>> Harbs
>>>
>>>> On Aug 3, 2017, at 6:24 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>
>>>> Right, so layout code would have to check for display=="none" and not
>>>> set
>>>> display and listen for the show event.
>>>>
>>>> Maybe as you clean up the setting of display multiple times it will be
>>>> come clear as to whether listening for "show" is cheaper/cleaner than
>>>> displayStyleForLayout.
>>>>
>>>> -Alex
>>>>
>>>> On 8/3/17, 8:18 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> The problem is that visible is set before the bead exists.
>>>>>
>>>>> BTW, Some of the layout seem to be reading and setting display multiple
>>>>> times. That can cause layout thrashing. That should probably be
>>>>> resolved.
>>>>>
>>>>>> On Aug 3, 2017, at 6:05 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>> wrote:
>>>>>>
>>>>>> FWIW, I'm not sure this is the best pattern. It was what we did to
>>>>>> get
>>>>>> the examples to run.
>>>>>>
>>>>>> Another option is that layout beads listen for changes to visible and
>>>>>> reset the CSS display style when visible changes.
>>>>>>
>>>>>> Food for thought,
>>>>>> -Alex
>>>>>>
>>>>>> On 8/3/17, 8:00 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>
>>>>>>> I’m using a VerticalFlexLayout in a component. Under certain
>>>>>>> circumstances, I need to set the visibility of the component to
>>>>>>> false.
>>>>>>>
>>>>>>> These two settings are contradictory in JS.
>>>>>>>
>>>>>>> visible=false sets display to none
>>>>>>> VerticalFlexLayout sets the display to flex
>>>>>>>
>>>>>>> When setting visible to false, it uses a property
>>>>>>> “displayStyleForLayout”
>>>>>>> to store the value set by the layout. The problem is that the layout
>>>>>>> might be applied AFTER visible is already set to false (which is the
>>>>>>> case
>>>>>>> in my situation).
>>>>>>>
>>>>>>> I’m thinking of solving this by exposing displayStyleForLayout so it
>>>>>>> can
>>>>>>> be set by beads if necessary.
>>>>>>>
>>>>>>> Scratch that. I see that already exists. Problem solved… I’ll fix the
>>>>>>> layouts.
>>>>>>>
>>>>>>> Harbs
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: FlexJS Bead dilemma
Posted by Harbs <ha...@gmail.com>.
Yes. I think that’s it.
Postponing layout on any non-visible element is something we probably want to do.
> On Aug 5, 2017, at 9:50 PM, yishayw <yi...@hotmail.com> wrote:
>
> You might be referring to what we did with Accordion. There, I added
> AccordionItemRendererView which does the following:
>
> override protected function performLayout(event:Event):void
> + {
> + var collapsibleStrand:ICollapsible = _strand as
> ICollapsible;
> + if (!collapsibleStrand.collapsed)
> + {
> + super.performLayout(event);
> + } else // skip layout for viewport children
> + {
> + layoutViewBeforeContentLayout();
> + layoutViewAfterContentLayout();
> + }
> + }
> :
>
>
>
> --
> View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Bead-dilemma-tp63681p63698.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS Bead dilemma
Posted by yishayw <yi...@hotmail.com>.
You might be referring to what we did with Accordion. There, I added
AccordionItemRendererView which does the following:
override protected function performLayout(event:Event):void
+ {
+ var collapsibleStrand:ICollapsible = _strand as
ICollapsible;
+ if (!collapsibleStrand.collapsed)
+ {
+ super.performLayout(event);
+ } else // skip layout for viewport children
+ {
+ layoutViewBeforeContentLayout();
+ layoutViewAfterContentLayout();
+ }
+ }
:
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Bead-dilemma-tp63681p63698.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: FlexJS Bead dilemma
Posted by Harbs <ha...@gmail.com>.
My ideas on bead lifecycles might help for this. Not sure.
I’m not sure there’s a perfect solution to this problem.
If I have to weigh a single check for visible vs an entire layout, I’d go for the former.
I seem to recall that we did something to prevent non-visible components for going throw layout, but I don’t remember any details. Maybe Yishay knows what I’m talking about.
> On Aug 3, 2017, at 7:18 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Yeah, but I also remembered on other thing. The vast majority of
> components are never made invisible, so adding a check in each layout bead
> just-in-case they are made invisible isn't very PAYG.
>
> So maybe there is some other way that setting visible=false can inject
> code that handles sharing the CSS display property with the layouts. Or
> maybe it isn't worth worrying about right now.
>
> My 2 cents,
> -Alex
>
> On 8/3/17, 8:50 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> But it it doesn’t set display, we’re going to have to run layout every
>> time the visibility changes.
>>
>> I’ve already made my changes. I’ll commit soon.
>>
>> Ah. I see what you mean. By doing it your way, there’s no reason to
>> actually run layout until (or if) the visibility is set to true.
>>
>> That probably *is* better. I’ll commit what I did for now, because it at
>> least fixes the bug, and when I have time, I’ll look into improving the
>> layouts.
>>
>> Another thought:
>>
>> If visibility is turned on and off multiple times, this might be less
>> efficient, but the layout might be able to store a flag to avoid running
>> the layout if not needed…
>>
>> Harbs
>>
>>> On Aug 3, 2017, at 6:24 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> Right, so layout code would have to check for display=="none" and not
>>> set
>>> display and listen for the show event.
>>>
>>> Maybe as you clean up the setting of display multiple times it will be
>>> come clear as to whether listening for "show" is cheaper/cleaner than
>>> displayStyleForLayout.
>>>
>>> -Alex
>>>
>>> On 8/3/17, 8:18 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> The problem is that visible is set before the bead exists.
>>>>
>>>> BTW, Some of the layout seem to be reading and setting display multiple
>>>> times. That can cause layout thrashing. That should probably be
>>>> resolved.
>>>>
>>>>> On Aug 3, 2017, at 6:05 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> FWIW, I'm not sure this is the best pattern. It was what we did to
>>>>> get
>>>>> the examples to run.
>>>>>
>>>>> Another option is that layout beads listen for changes to visible and
>>>>> reset the CSS display style when visible changes.
>>>>>
>>>>> Food for thought,
>>>>> -Alex
>>>>>
>>>>> On 8/3/17, 8:00 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> I’m using a VerticalFlexLayout in a component. Under certain
>>>>>> circumstances, I need to set the visibility of the component to
>>>>>> false.
>>>>>>
>>>>>> These two settings are contradictory in JS.
>>>>>>
>>>>>> visible=false sets display to none
>>>>>> VerticalFlexLayout sets the display to flex
>>>>>>
>>>>>> When setting visible to false, it uses a property
>>>>>> “displayStyleForLayout”
>>>>>> to store the value set by the layout. The problem is that the layout
>>>>>> might be applied AFTER visible is already set to false (which is the
>>>>>> case
>>>>>> in my situation).
>>>>>>
>>>>>> I’m thinking of solving this by exposing displayStyleForLayout so it
>>>>>> can
>>>>>> be set by beads if necessary.
>>>>>>
>>>>>> Scratch that. I see that already exists. Problem solved… I’ll fix the
>>>>>> layouts.
>>>>>>
>>>>>> Harbs
>>>>>
>>>>
>>>
>>
>
Re: FlexJS Bead dilemma
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Yeah, but I also remembered on other thing. The vast majority of
components are never made invisible, so adding a check in each layout bead
just-in-case they are made invisible isn't very PAYG.
So maybe there is some other way that setting visible=false can inject
code that handles sharing the CSS display property with the layouts. Or
maybe it isn't worth worrying about right now.
My 2 cents,
-Alex
On 8/3/17, 8:50 AM, "Harbs" <ha...@gmail.com> wrote:
>But it it doesn’t set display, we’re going to have to run layout every
>time the visibility changes.
>
>I’ve already made my changes. I’ll commit soon.
>
>Ah. I see what you mean. By doing it your way, there’s no reason to
>actually run layout until (or if) the visibility is set to true.
>
>That probably *is* better. I’ll commit what I did for now, because it at
>least fixes the bug, and when I have time, I’ll look into improving the
>layouts.
>
>Another thought:
>
>If visibility is turned on and off multiple times, this might be less
>efficient, but the layout might be able to store a flag to avoid running
>the layout if not needed…
>
>Harbs
>
>> On Aug 3, 2017, at 6:24 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Right, so layout code would have to check for display=="none" and not
>>set
>> display and listen for the show event.
>>
>> Maybe as you clean up the setting of display multiple times it will be
>> come clear as to whether listening for "show" is cheaper/cleaner than
>> displayStyleForLayout.
>>
>> -Alex
>>
>> On 8/3/17, 8:18 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> The problem is that visible is set before the bead exists.
>>>
>>> BTW, Some of the layout seem to be reading and setting display multiple
>>> times. That can cause layout thrashing. That should probably be
>>>resolved.
>>>
>>>> On Aug 3, 2017, at 6:05 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>wrote:
>>>>
>>>> FWIW, I'm not sure this is the best pattern. It was what we did to
>>>>get
>>>> the examples to run.
>>>>
>>>> Another option is that layout beads listen for changes to visible and
>>>> reset the CSS display style when visible changes.
>>>>
>>>> Food for thought,
>>>> -Alex
>>>>
>>>> On 8/3/17, 8:00 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> I’m using a VerticalFlexLayout in a component. Under certain
>>>>> circumstances, I need to set the visibility of the component to
>>>>>false.
>>>>>
>>>>> These two settings are contradictory in JS.
>>>>>
>>>>> visible=false sets display to none
>>>>> VerticalFlexLayout sets the display to flex
>>>>>
>>>>> When setting visible to false, it uses a property
>>>>> “displayStyleForLayout”
>>>>> to store the value set by the layout. The problem is that the layout
>>>>> might be applied AFTER visible is already set to false (which is the
>>>>> case
>>>>> in my situation).
>>>>>
>>>>> I’m thinking of solving this by exposing displayStyleForLayout so it
>>>>> can
>>>>> be set by beads if necessary.
>>>>>
>>>>> Scratch that. I see that already exists. Problem solved… I’ll fix the
>>>>> layouts.
>>>>>
>>>>> Harbs
>>>>
>>>
>>
>
Re: FlexJS Bead dilemma
Posted by Harbs <ha...@gmail.com>.
But it it doesn’t set display, we’re going to have to run layout every time the visibility changes.
I’ve already made my changes. I’ll commit soon.
Ah. I see what you mean. By doing it your way, there’s no reason to actually run layout until (or if) the visibility is set to true.
That probably *is* better. I’ll commit what I did for now, because it at least fixes the bug, and when I have time, I’ll look into improving the layouts.
Another thought:
If visibility is turned on and off multiple times, this might be less efficient, but the layout might be able to store a flag to avoid running the layout if not needed…
Harbs
> On Aug 3, 2017, at 6:24 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Right, so layout code would have to check for display=="none" and not set
> display and listen for the show event.
>
> Maybe as you clean up the setting of display multiple times it will be
> come clear as to whether listening for "show" is cheaper/cleaner than
> displayStyleForLayout.
>
> -Alex
>
> On 8/3/17, 8:18 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> The problem is that visible is set before the bead exists.
>>
>> BTW, Some of the layout seem to be reading and setting display multiple
>> times. That can cause layout thrashing. That should probably be resolved.
>>
>>> On Aug 3, 2017, at 6:05 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>
>>> FWIW, I'm not sure this is the best pattern. It was what we did to get
>>> the examples to run.
>>>
>>> Another option is that layout beads listen for changes to visible and
>>> reset the CSS display style when visible changes.
>>>
>>> Food for thought,
>>> -Alex
>>>
>>> On 8/3/17, 8:00 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> I’m using a VerticalFlexLayout in a component. Under certain
>>>> circumstances, I need to set the visibility of the component to false.
>>>>
>>>> These two settings are contradictory in JS.
>>>>
>>>> visible=false sets display to none
>>>> VerticalFlexLayout sets the display to flex
>>>>
>>>> When setting visible to false, it uses a property
>>>> “displayStyleForLayout”
>>>> to store the value set by the layout. The problem is that the layout
>>>> might be applied AFTER visible is already set to false (which is the
>>>> case
>>>> in my situation).
>>>>
>>>> I’m thinking of solving this by exposing displayStyleForLayout so it
>>>> can
>>>> be set by beads if necessary.
>>>>
>>>> Scratch that. I see that already exists. Problem solved… I’ll fix the
>>>> layouts.
>>>>
>>>> Harbs
>>>
>>
>
Re: FlexJS Bead dilemma
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Right, so layout code would have to check for display=="none" and not set
display and listen for the show event.
Maybe as you clean up the setting of display multiple times it will be
come clear as to whether listening for "show" is cheaper/cleaner than
displayStyleForLayout.
-Alex
On 8/3/17, 8:18 AM, "Harbs" <ha...@gmail.com> wrote:
>The problem is that visible is set before the bead exists.
>
>BTW, Some of the layout seem to be reading and setting display multiple
>times. That can cause layout thrashing. That should probably be resolved.
>
>> On Aug 3, 2017, at 6:05 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> FWIW, I'm not sure this is the best pattern. It was what we did to get
>> the examples to run.
>>
>> Another option is that layout beads listen for changes to visible and
>> reset the CSS display style when visible changes.
>>
>> Food for thought,
>> -Alex
>>
>> On 8/3/17, 8:00 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> I’m using a VerticalFlexLayout in a component. Under certain
>>> circumstances, I need to set the visibility of the component to false.
>>>
>>> These two settings are contradictory in JS.
>>>
>>> visible=false sets display to none
>>> VerticalFlexLayout sets the display to flex
>>>
>>> When setting visible to false, it uses a property
>>>“displayStyleForLayout”
>>> to store the value set by the layout. The problem is that the layout
>>> might be applied AFTER visible is already set to false (which is the
>>>case
>>> in my situation).
>>>
>>> I’m thinking of solving this by exposing displayStyleForLayout so it
>>>can
>>> be set by beads if necessary.
>>>
>>> Scratch that. I see that already exists. Problem solved… I’ll fix the
>>> layouts.
>>>
>>> Harbs
>>
>
Re: FlexJS Bead dilemma
Posted by Harbs <ha...@gmail.com>.
The problem is that visible is set before the bead exists.
BTW, Some of the layout seem to be reading and setting display multiple times. That can cause layout thrashing. That should probably be resolved.
> On Aug 3, 2017, at 6:05 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> FWIW, I'm not sure this is the best pattern. It was what we did to get
> the examples to run.
>
> Another option is that layout beads listen for changes to visible and
> reset the CSS display style when visible changes.
>
> Food for thought,
> -Alex
>
> On 8/3/17, 8:00 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> I’m using a VerticalFlexLayout in a component. Under certain
>> circumstances, I need to set the visibility of the component to false.
>>
>> These two settings are contradictory in JS.
>>
>> visible=false sets display to none
>> VerticalFlexLayout sets the display to flex
>>
>> When setting visible to false, it uses a property “displayStyleForLayout”
>> to store the value set by the layout. The problem is that the layout
>> might be applied AFTER visible is already set to false (which is the case
>> in my situation).
>>
>> I’m thinking of solving this by exposing displayStyleForLayout so it can
>> be set by beads if necessary.
>>
>> Scratch that. I see that already exists. Problem solved… I’ll fix the
>> layouts.
>>
>> Harbs
>
Re: FlexJS Bead dilemma
Posted by Alex Harui <ah...@adobe.com.INVALID>.
FWIW, I'm not sure this is the best pattern. It was what we did to get
the examples to run.
Another option is that layout beads listen for changes to visible and
reset the CSS display style when visible changes.
Food for thought,
-Alex
On 8/3/17, 8:00 AM, "Harbs" <ha...@gmail.com> wrote:
>I’m using a VerticalFlexLayout in a component. Under certain
>circumstances, I need to set the visibility of the component to false.
>
>These two settings are contradictory in JS.
>
>visible=false sets display to none
>VerticalFlexLayout sets the display to flex
>
>When setting visible to false, it uses a property “displayStyleForLayout”
>to store the value set by the layout. The problem is that the layout
>might be applied AFTER visible is already set to false (which is the case
>in my situation).
>
>I’m thinking of solving this by exposing displayStyleForLayout so it can
>be set by beads if necessary.
>
>Scratch that. I see that already exists. Problem solved… I’ll fix the
>layouts.
>
>Harbs