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
