I implemented the basics of my idea here: https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7 <https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7>
I got my inspiration from PureMVC. I only made enough changes to get rid of compiler errors in Core. There’s still a lot of work I’d need to do to make it functional, but you should be able to see the architecture from that commit. Basically I added to IBead: listInterests() which allows the strand to extract from a bead what notifications it wants and: handleNotification() where the strand sends the notification to the bead. Strand got notify() and sendNotification(). Those two methods should replace virtually every use of dispatchEvent() currently being used except when it’s a legitimate event. Clean addition and removal of beads is actually already implemented in my POC. Check out the utility functions in org.apache.royale.utils.beads What do folks think? Harbs > On Jan 29, 2019, at 2:10 PM, Carlos Rovira <[email protected]> wrote: > > That sounds good Harbs, > you could that of if you want to save some effort, first make a new email > thread with some example of code on how this would look in the end, so we > all can understand it and provide some feedback so your effort could be > more easy in the end. > > El lun., 28 ene. 2019 a las 17:26, Harbs (<[email protected] > <mailto:[email protected]>>) escribió: > >> 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]> <mailto: >> [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] >>> <mailto:[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] >>>>> <mailto:[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] >>>>>> <mailto:[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] <mailto:[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> >> < >> 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> >> < >> 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> >> < >> 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 > http://about.me/carlosrovira <http://about.me/carlosrovira>
