Agree too. We can have more beads to give options as already happens in other parts of Royale. So don't see a problem your stacked version could come in. Also, as I have time, I could review and see if I could provide some support so we can get all of it more integrated... Most of the things in Jewel are not finished and I have things in mind that still could not work on it due to my actual time constraints, and in the other hand having a full feature UI Set with themes and all the things we need to consider 1.0 is a lot of work. But I hope this year 2019, we could get to a very high percent of completion on Jewel to consider almost finished (although is clear that this kind of things are never finished ;))
El lun., 28 ene. 2019 a las 22:08, Alex Harui (<aha...@adobe.com.invalid>) escribió: > Just give your version a different name that describes what it is and > commit it to Royale. Royale gives folks choices. > > My 2 cents, > -Alex > > On 1/28/19, 12:01 PM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> wrote: > > 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%7Cb51f381c71be4499944108d6855b61cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636843024863001924&sdata=9NWPp1ZjHuCtWNMh0ArvKtBju%2FAt78kildBIJ0zpnAE%3D&reserved=0 > > < > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb51f381c71be4499944108d6855b61cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636843024863001924&sdata=9NWPp1ZjHuCtWNMh0ArvKtBju%2FAt78kildBIJ0zpnAE%3D&reserved=0 > > > > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> -- > > >>>> Carlos Rovira > > >>>> > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb51f381c71be4499944108d6855b61cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636843024863001924&sdata=9NWPp1ZjHuCtWNMh0ArvKtBju%2FAt78kildBIJ0zpnAE%3D&reserved=0 > > < > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb51f381c71be4499944108d6855b61cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636843024863001924&sdata=9NWPp1ZjHuCtWNMh0ArvKtBju%2FAt78kildBIJ0zpnAE%3D&reserved=0 > > > > > >>> > > >> > > >> > > > > > > -- > > > Carlos Rovira > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb51f381c71be4499944108d6855b61cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636843024863001924&sdata=9NWPp1ZjHuCtWNMh0ArvKtBju%2FAt78kildBIJ0zpnAE%3D&reserved=0 > > < > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cb51f381c71be4499944108d6855b61cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636843024863001924&sdata=9NWPp1ZjHuCtWNMh0ArvKtBju%2FAt78kildBIJ0zpnAE%3D&reserved=0 > > > > > > > > > > > -- > > Piotr Zarzycki > > Patreon: * > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb51f381c71be4499944108d6855b61cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636843024863001924&sdata=xieep8fiq3A915CQNTPczdy5eJAP%2BDawSCr5dS%2BzRdY%3D&reserved=0 > < > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb51f381c71be4499944108d6855b61cb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636843024863001924&sdata=xieep8fiq3A915CQNTPczdy5eJAP%2BDawSCr5dS%2BzRdY%3D&reserved=0 > >* > > > -- Carlos Rovira http://about.me/carlosrovira
