Guys, Many thanks for all your thoughts. Harbs thank you for this utility it will be very useful. I think I'm ok with having some specialized stuff which is doing things like removing bead etc. I did small clean up of FormItemView and put it in other thread.
I wrote also StackedFormView but I didn't commit it to Royale cause Carlos is seeing it a bit differently than my requirements. If someone would like to have it I will probably put it in transpiledactionscript. My Stacked is: L* C Carlos propose to have it as in Flex: L C* L - Label - title C - Content * - required asterix Thanks, Piotr pon., 28 sty 2019 o 19:10 Alex Harui <aha...@adobe.com.invalid> napisał(a): > IMO, either use a few more words to describe it here, or show the code in > a branch. I don't think the generic problem of cleaning up an instance > from an external instance is solvable, but maybe there are sweet spots > along the way. > > -Alex > > On 1/28/19, 8:26 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > 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%7C629bc21a49c5414559c808d6853d6025%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842896082091861&sdata=cCoJJhusdR%2FLjHR4dl5kVIFG%2B3fdf4RERQVwELV6MTc%3D&reserved=0 > < > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C629bc21a49c5414559c808d6853d6025%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842896082091861&sdata=cCoJJhusdR%2FLjHR4dl5kVIFG%2B3fdf4RERQVwELV6MTc%3D&reserved=0 > > > >>>>> > >>>>> > >>>>> > >>>> > >>>> -- > >>>> Carlos Rovira > >>>> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C629bc21a49c5414559c808d6853d6025%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842896082091861&sdata=cCoJJhusdR%2FLjHR4dl5kVIFG%2B3fdf4RERQVwELV6MTc%3D&reserved=0 > < > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C629bc21a49c5414559c808d6853d6025%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842896082101866&sdata=mwHbqna6uLLN9SphMlWFySQNtVLxiUoVmD6whlyrYLs%3D&reserved=0 > > > >>> > >> > >> > > > > -- > > Carlos Rovira > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C629bc21a49c5414559c808d6853d6025%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842896082101866&sdata=mwHbqna6uLLN9SphMlWFySQNtVLxiUoVmD6whlyrYLs%3D&reserved=0 > < > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C629bc21a49c5414559c808d6853d6025%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636842896082101866&sdata=mwHbqna6uLLN9SphMlWFySQNtVLxiUoVmD6whlyrYLs%3D&reserved=0 > > > > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
