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" <harbs.li...@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 <aha...@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" <harbs.li...@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 <aha...@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" <yishayj...@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<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 >>>>>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" <yishayj...@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 <aha...@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" <yishayj...@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. >>>>>> >>>>> >>>> >>> >> >
