Hi Alex, El lun., 28 ene. 2019 a las 17:22, Alex Harui (<aha...@adobe.com.invalid>) escribió:
> 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. > what I was suggesting is not to have that version of the bead in our repo, but that people that really need it do it themselves. I think for us is ok to have just the replaceBead function. > > 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. > ok, I was not thinking on that. So for me is ok. > > 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. > thinking more over it and getting some "external" way to do that cleaning would be great, but don't know if would be possible. > > 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. > interesting idea :) > > HTH, > -Alex > > On 1/28/19, 2:57 AM, "Carlos Rovira" <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 > > >>> > > >>> > > >>> > > >> > > >> -- > > >> 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 > > > > > > > > > -- > 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> > 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> > http://about.me/carlosrovira > > >
