https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-2b4ced1196f39150a85b0cd61bbb338dL64 https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-1579cf5aa28be79326d96804b8ff5b85R95 <https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-1579cf5aa28be79326d96804b8ff5b85R95> https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-7b616cac43f87537a5c667f91f1b332fR54
https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-75385354048a329d33d5708f25f4befdR41 <https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-75385354048a329d33d5708f25f4befdR41> https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84 <https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84> > On Feb 1, 2019, at 12:06 AM, Carlos Rovira <[email protected]> wrote: > > Sorry Harbs, > very busy this days. Very interested in take a look. Just one question. A > part from the implementation did you commit some example of use, so I can > differentiate clearly the code that is using this notification system > > thanks! > > El jue., 31 ene. 2019 a las 18:04, Alex Harui (<[email protected]>) > escribió: > >> I hope to look at this on the weekend. >> >> -Alex >> >> On 1/31/19, 4:17 AM, "Harbs" <[email protected]> wrote: >> >> Bump. >> >> Anyone have opinions on this? >> >>> On Jan 30, 2019, at 12:47 PM, Harbs <[email protected]> wrote: >>> >>> I implemented the basics of my idea here: >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=2cEb3AFiH0Y31i0z0FFDHVGYJFzBlOJDMBoDME7w5F8%3D&reserved=0 >> < >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=2cEb3AFiH0Y31i0z0FFDHVGYJFzBlOJDMBoDME7w5F8%3D&reserved=0 >>> >>> >>> 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] >> <mailto:[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] >> <mailto:[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] <mailto:[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%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >> < >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >>> >>>>> < >>>>> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >> < >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Carlos Rovira >>>>>>>>> >>>>> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >> < >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >>> >>>>> < >>>>> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >> < >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >>> >>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Carlos Rovira >>>>>> >>>>> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >> < >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >>> >>>>> < >>>>> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >> < >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Carlos Rovira >>>> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >> < >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0 >>> >> >> >> >> > > -- > Carlos Rovira > http://about.me/carlosrovira
