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>*
