Good point. If we would implement my idea of notifications, we could use utility functions to clean out beads.
If anyone is interested in this direction, I can write an implementation in a branch to show what I’m talking about… Harbs > On Jan 28, 2019, at 6:22 PM, Alex Harui <[email protected]> wrote: > > It is fine to have a utility function such as this, but IMO, it doesn't > actually solve the problem. If the original bead does not know how to remove > itself, then a version of that bead needs to be created that does know how to > remove itself. While we could add replaceable versions of every bead, that > would flood the documentation and code-intelligence eventually. > > Replacing beads should be a rare occurrence and the APIs should indicate > that. I guess I am not making myself clear, but every time I say we are > going to remove "removeBead" I always say that there will be a utility > function to do it and then someone responds with "hey we still need a way to > do this". That way is the utility function. > > It might turn out that there is a way to write most beads in a way that > another bead can clean it up. That requires making event handlers public > instead of private/protected, which isn't my favorite idea since it also > clutters code-intelligence and documentation. > > One other idea along these lines that I've never tried is a "splitter bead". > In electronics and elsewhere, a splitter allows one plug to plug in two > things, with an optional switch. So a LayoutSplitterBead (which is also a > strand) would allow both a HorizontalLayout and VerticalLayout to be on its > strand, and have some flag that switches which layout is in play by > redirecting calls to one of the two beads. > > HTH, > -Alex > > On 1/28/19, 2:57 AM, "Carlos Rovira" <[email protected] > <mailto:[email protected]>> wrote: > > Hi Harbs > > this seems to me the right way to go. > > In the current case, I think Jewel should not know about how to clean > itself since is not PAYG. So Piotr should subclass the bead and add the > clean up functionality an configure as default in this project. Then use > your replaceBead to do the change > > thanks all for taking a look, I think we got it :) > > @Piotr solves that your problem? > > Carlos > > > El lun., 28 ene. 2019 a las 11:20, Harbs (<[email protected]>) > escribió: > >> 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 <[email protected]> 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 <[email protected]> >> 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 (<[email protected] >>> ) >>>> 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" <[email protected]> >> 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%7C06444dc5a01f481720c508d6850f575b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842698295215163&sdata=lpaCipQPwqEiVaAD7CaKYY8qp5GKHog4nS7dIsoLmyM%3D&reserved=0 >> >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C06444dc5a01f481720c508d6850f575b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842698295215163&sdata=lpaCipQPwqEiVaAD7CaKYY8qp5GKHog4nS7dIsoLmyM%3D&reserved=0> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Carlos Rovira >>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C06444dc5a01f481720c508d6850f575b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842698295215163&sdata=lpaCipQPwqEiVaAD7CaKYY8qp5GKHog4nS7dIsoLmyM%3D&reserved=0 >>>> >>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C06444dc5a01f481720c508d6850f575b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842698295215163&sdata=lpaCipQPwqEiVaAD7CaKYY8qp5GKHog4nS7dIsoLmyM%3D&reserved=0> >>> >> >> > > -- > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C06444dc5a01f481720c508d6850f575b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842698295215163&sdata=lpaCipQPwqEiVaAD7CaKYY8qp5GKHog4nS7dIsoLmyM%3D&reserved=0 > > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C06444dc5a01f481720c508d6850f575b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842698295215163&sdata=lpaCipQPwqEiVaAD7CaKYY8qp5GKHog4nS7dIsoLmyM%3D&reserved=0>
