FlexJS Bead dilemma

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

FlexJS Bead dilemma

Harbs
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS Bead dilemma

Alex Harui-2
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" <[hidden email]> 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

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

Re: FlexJS Bead dilemma

Harbs
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 <[hidden email]> 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" <[hidden email]> 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
>

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

Re: FlexJS Bead dilemma

Alex Harui-2
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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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
>>
>

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

Re: FlexJS Bead dilemma

Harbs
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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
>>>
>>
>

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

Re: FlexJS Bead dilemma

Alex Harui-2
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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>>>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" <[hidden email]> 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
>>>>
>>>
>>
>

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

Re: FlexJS Bead dilemma

Harbs
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>>>> 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" <[hidden email]> 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
>>>>>
>>>>
>>>
>>
>

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

Re: FlexJS Bead dilemma

yishayw
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();
+                       }
+               }
:
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS Bead dilemma

Harbs
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 <[hidden email]> 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.

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

Re: FlexJS Bead dilemma

Harbs
In reply to this post by Harbs
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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>>>>> 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" <[hidden email]> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

RE: FlexJS Bead dilemma

yishayw




>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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>>>>> 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" <[hidden email]> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>


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

Re: FlexJS Bead dilemma

Alex Harui-2
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>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" <[hidden email]> 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 <[hidden email]>
>>>>>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" <[hidden email]> 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 <[hidden email]>
>>>>>>> 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" <[hidden email]> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>

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

Re: FlexJS Bead dilemma

yishayw
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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FlexJS Bead dilemma

Alex Harui-2
<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" <[hidden email]> 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.

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

Re: FlexJS Bead dilemma

yishayw
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 <[hidden email]>
Sent: Monday, August 7, 2017 6:58:29 PM
To: [hidden email]
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" <[hidden email]> 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.

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

Re: FlexJS Bead dilemma

Alex Harui-2
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" <[hidden email]> 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 <[hidden email]>
>Sent: Monday, August 7, 2017 6:58:29 PM
>To: [hidden email]
>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" <[hidden email]> 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.
>

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

RE: FlexJS Bead dilemma

yishayw
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<mailto:[hidden email]>
Sent: Tuesday, August 8, 2017 8:55 AM
To: [hidden email]<mailto:[hidden email]>
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" <[hidden email]> 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 <[hidden email]>
>Sent: Monday, August 7, 2017 6:58:29 PM
>To: [hidden email]
>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" <[hidden email]> 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.
>

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

Re: FlexJS Bead dilemma

Alex Harui-2
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" <[hidden email]> 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<mailto:[hidden email]>
>Sent: Tuesday, August 8, 2017 8:55 AM
>To: [hidden email]<mailto:[hidden email]>
>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" <[hidden email]> 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 <[hidden email]>
>>Sent: Monday, August 7, 2017 6:58:29 PM
>>To: [hidden email]
>>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" <[hidden email]> 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.
>>
>

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

Re: FlexJS Bead dilemma

Harbs
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 <[hidden email]> 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" <[hidden email]> 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<mailto:[hidden email]>
>> Sent: Tuesday, August 8, 2017 8:55 AM
>> To: [hidden email]<mailto:[hidden email]>
>> 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" <[hidden email]> 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 <[hidden email]>
>>> Sent: Monday, August 7, 2017 6:58:29 PM
>>> To: [hidden email]
>>> 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" <[hidden email]> 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.
>>>
>>
>

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

Re: FlexJS Bead dilemma

Alex Harui-2
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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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<mailto:[hidden email]>
>>> Sent: Tuesday, August 8, 2017 8:55 AM
>>> To: [hidden email]<mailto:[hidden email]>
>>> 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" <[hidden email]> 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 <[hidden email]>
>>>> Sent: Monday, August 7, 2017 6:58:29 PM
>>>> To: [hidden email]
>>>> 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" <[hidden email]> 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.
>>>>
>>>
>>
>

12
Loading...