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 (<aha...@adobe.com.invalid>) escribió: > I hope to look at this on the weekend. > > -Alex > > On 1/31/19, 4:17 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > Bump. > > Anyone have opinions on this? > > > On Jan 30, 2019, at 12:47 PM, Harbs <harbs.li...@gmail.com> 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 <carlosrov...@apache.org > <mailto:carlosrov...@apache.org>> 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 (<harbs.li...@gmail.com > <mailto:harbs.li...@gmail.com>>) 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 <aha...@adobe.com.INVALID > <mailto:aha...@adobe.com.INVALID>> > >>> 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" <carlosrov...@apache.org > <mailto:carlosrov...@apache.org> <mailto: > >>> carlosrov...@apache.org <mailto:carlosrov...@apache.org>>> 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 (< > harbs.li...@gmail.com <mailto:harbs.li...@gmail.com>>) > >>> 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 <harbs.li...@gmail.com > <mailto:harbs.li...@gmail.com>> 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 < > carlosrov...@apache.org <mailto: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 <mailto: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 <mailto: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%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
