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>) 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> > 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>> 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>) > 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> 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> > >> 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 > >>> ) > >>>> 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> > >> 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 > > > -- Carlos Rovira http://about.me/carlosrovira
