I just added a utility function for this. I thought of checking to see if the bead has a beadRemoved() method and conditionally calling that, but it seemed not PAYG and hacky.
My thoughts are to use this like so: var removedBead:MyBeadThatKnowsHowToCleaupAfterItself = replaceBead(strand, newBead,ILayoutBead); if(removedBead)removedBead.cleanup(); > On Jan 28, 2019, at 12:06 PM, Harbs <harbs.li...@gmail.com> wrote: > > I mentioned a long time ago that I really want to implement a notification > system for strands and beads. I’ve always felt that events are kind of hacky. > > I would require a little bit of scaffolding for the notifications so it’s not > truly PAYG, but the notifications could really be plug and play. I think the > net result would be less code as opposed to the current system of sending > events. > > For this case, I think a replaceBead() utility function would probably do the > trick. > >> On Jan 28, 2019, at 10:38 AM, Carlos Rovira <carlosrov...@apache.org> wrote: >> >> HI Alex >> >> mostly agree with your thoughts. Just some points: >> >> * While I think beads should be "instantiation time", don't agree with >> wanting to remove the "removeBead" method. We're a framework, and people >> will find this problem. So is difficult to explain the we don't have any >> way to do this >> * In the other hand, I think we should have as you proposed in your >> response, some utility function to handle this, so people could manage it >> in this strange case. >> >> So, finally, I think Piotr, should create a class function or something >> like this. If he can do something generalist, that could go to our repo, if >> is something more tied to his code, that should go to his codebase. >> >> Thoughts? >> >> >> El lun., 28 ene. 2019 a las 6:40, Alex Harui (<aha...@adobe.com.invalid>) >> escribió: >> >>> I know there have been other responses, but I think this original post is >>> the best place for my response. >>> >>> IMO, sealed classes are another safety/security measure. Changing the >>> code in a class at runtime invites opportunities for hacking that are >>> really hard to detect. The set of beads assigned to a strand would be >>> instantiated in the constructor if we could do it that early, but we want >>> to allow someone to declare options/overrides of default behavior and the >>> only practical way to do it is to wait a bit. But once the instantiation >>> lifecycle is over, you really should be able to examine what the instance >>> is composed of. It shouldn't change later. Later changes create all >>> kinds of havoc for code coverage tools, debugging, and other productivity >>> issues. >>> >>> So, IMO, it is best to try to make the composition of an instance >>> declarable at author-time. If you need to specify something for an inner >>> child, we have ways of doing that. ItemRenderers specify the inner >>> children of a list. A Panel's TitleBar can be swapped for a different >>> titlebar. If you want a component that can switch between laying out >>> horizontally and vertically, you could use states or other techniques to >>> swap between a child with HorizonalLayout and a child with VerticalLayout, >>> but changing a single child's beads at runtime is not a best practice. You >>> could also create a VerticalOrHorizontalLayout bead. All of these >>> techniques make it easier to see at author-time what the pieces are. That >>> way, when debugging into the child where the MXML/CSS said HorizontalLayout >>> and you see a VerticalLayout, you are less likely to be surprised and >>> think there is a bug in the layout assignment when there isn't. >>> >>> And thus, because of PAYG, none of our existing beads carry code around to >>> cleanup if removed from the strand, and I've mentioned recently that I >>> seriously considering we should take removeBead out of IStrand and UIBase. >>> However, I agree with whoever responded that we shouldn't block bead >>> removal. We should just make it a truly rare occurrence. Somebody, some >>> day, will come up with a rare reason to need it. But they will need to use >>> beads that carry extra code that does the clean up and call some utility >>> function that removes the bead from the strand. >>> >>> So, I don't fully understand this scenario and am too backlogged to really >>> dig through it, but please first attempt to find patterns that allow >>> specification of the children and their layout at author-time. Think of >>> beads as an instantiation-time composition of a class instance. Then >>> consider beads that can go "both ways". Then consider beads that can be >>> removed. But for PAYG reasons, we don't want to have all beads know how to >>> be removed. >>> >>> My 2 cents, >>> -Alex >>> >>> On 1/27/19, 12:26 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: >>> >>> Hi, >>> >>> Piotr and I found a situation where we don't know how to solve with >>> some >>> generalist solution. Hope others here could give some ideas. >>> >>> The setup: We have a layout bead that decorates the strand with a css >>> class >>> selector. The bead is configured in CSS as a default bead >>> >>> The problem: We found that adding another layout bead at runtime that >>> "substitute" the default bead and adds other CSS class selector, left >>> the >>> selector(s) from the old layout bead untouched. >>> >>> Notice that adding the new layout bead in MXML through beads array is >>> ok, >>> since (I think) default bead is never instantiated and the second one >>> is >>> the only one running its code. The problem happens if we try to do the >>> change at runtime at a later time. >>> >>> So, our question is: How to deal with beads that are already >>> instantiated >>> and needs to be removed. How we should operate with it? Should be have >>> some >>> removal mechanism in Royale to do this? >>> >>> For more info and code about this issue, Piotr shared some source code >>> in >>> other recent thread about Jewel Group. >>> >>> Thanks >>> >>> -- >>> Carlos Rovira >>> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4278c26f3fb142d3b1d208d684311fa0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636841743883902882&sdata=K%2FN1izFMjQXpGQcGZfraUdrXYPuYniimcF5i0dKe1i8%3D&reserved=0 >>> >>> >>> >> >> -- >> Carlos Rovira >> http://about.me/carlosrovira >
