gt;>> 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
>>
gt;>>>
>>>> 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 wou
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
>>> bea
re 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<mailto:aha...@adobe.com.INVALID>
>> Sent
d which would be added before the layout
>bead. It would listen on ‘layoutNeeded’ and stopImmediatePropagation()
>unless the host is visible.
>
>From: Alex Harui<mailto:aha...@adobe.com.INVALID>
>Sent: Tuesday, August 8, 2017 8:55 AM
>To: dev@flex.apache.org<mailto:dev@flex.apache.org
eded’ and stopImmediatePropagation() unless the host
is visible.
From: Alex Harui<mailto:aha...@adobe.com.INVALID>
Sent: Tuesday, August 8, 2017 8:55 AM
To: dev@flex.apache.org<mailto:dev@flex.apache.org>
Subject: Re: FlexJS Bead dilemma
I was thinking the wrapper would just wait for the show event then
nd 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
>Sent: Monday, August 7, 2017 6:58:29 PM
>To:
classes).
Adding a meager LayoutOnShow bead seems cleaner to me.
From: Alex Harui
Sent: Monday, August 7, 2017 6:58:29 PM
To: dev@flex.apache.org
Subject: Re: FlexJS Bead dilemma
A bead could have a property which is another bead.
Of course
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" 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 w
347.n4.nabble.com/FlexJS-Bead-dilemma-tp63681p63726.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
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
>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,
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
layoutViewAfterContentLayout();
> + }
> + }
> :
>
>
>
> --
> View this message in context:
> http://apache-flex-development.247.n4.nabble.com/FlexJS-Bead-dilemma-tp63681p63698.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
+ {
+ layoutViewBeforeContentLayout();
+ layoutViewAfterContentLayout();
+ }
+ }
:
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-Bead-dilemma-tp63681p63698.html
Sent from the Apache Flex Development mailing list
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
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 CS
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
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:
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 wrote:
>
> FWIW, I'm not sure this is the best p
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" wrote:
>I’m using a VerticalF
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
22 matches
Mail list logo
