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>
