Sorry, meant this [1] one
[1] https://github.com/yishayw/Examples/tree/RunTimeLayout ________________________________ From: Carlos Rovira <carlosrov...@apache.org> Sent: Monday, January 28, 2019 10:29:11 AM To: dev@royale.apache.org Subject: Re: Problems dealing with bead substitution in Royale Hi Yishay, you're right. Jewel has NullLayout in some places since the component use to do things vía CSS, I need to refactor that to a layout bead to make it more decoupled. I announced that was temporal. But don't think the problem exposed in this thread is about setting null for a bead. Is more about, how to change a bead at runtime (so there's a previous bead and is not nulled) In the example you posted I only see a label instantiation, nothing more. Maybe is not the right example? thanks El dom., 27 ene. 2019 a las 21:53, Yishay Weiss (<yishayj...@hotmail.com>) escribió: > I agree writing ‘null’ in the css is a hack. I also noticed places in > Jewel’s defauts.css that had > > > > IBeadLayout: > ClassReference("org.apache.royale.jewel.beads.layouts.NullLayout"); > > > > Which seems pretty similar. > > > > I’m still not sure I understand the scenario. If you just need to create > beads in AS3, you can do so while overriding the default bead, as another > [1] example shows. > > > > [1] https://github.com/yishayw/Examples > > > > ________________________________ > From: Carlos Rovira <carlosrov...@apache.org> > Sent: Sunday, January 27, 2019 7:00:51 PM > To: dev@royale.apache.org > Subject: Re: Problems dealing with bead substitution in Royale > > Hi, > > Yishay, as Piotr said, it seems you're doing a workaround to solve the > current problem. But Royale is a framework. It's ok to use temporary > workarounds, but we must focus the way to make things as usable as > possible, optimal and with the less code possible. Don't know exactly why > Piotr wants to do this, but seems right to me that users would want to > change a bead at some point as part of the requirements in a given > application. So I think we should have some mechanism to manage the > substitution or removal of a bead for a new one of its kind > > > > El dom., 27 ene. 2019 a las 13:18, Piotr Zarzycki (< > piotrzarzyck...@gmail.com>) escribió: > > > Hi Harbs, > > > > When nested components is instantiated with default bead X, and after > > instantiation has been added new instance of Bead Y - Both Beads will > apply > > logic to that components. > > > > Example - Component has HorizontalLayout (declared in CSS) - I'm adding > > VerticalLayout by addBead and both are applied - in the results you have > > messed layout. > > > > Piotr > > > > On Sun, Jan 27, 2019, 1:13 PM Harbs <harbs.li...@gmail.com wrote: > > > > > I don’t understand the situation. > > > > > > Why is nested components an issue? > > > > > > > On Jan 27, 2019, at 1:26 PM, Piotr Zarzycki < > piotrzarzyck...@gmail.com > > > > > > wrote: > > > > > > > > Hi Yishay, > > > > > > > > Your example is showing how to avoid it, but user probably won't null > > > > anything in css. That's the situation. As for the scenario - Let's > say > > > that > > > > you have component which has inside of View instantiation of another > > > > component. Situation looks like that: > > > > > > > > <div> - first component with bead X > > > > <div></div> - second component with bead X, who have bead Y of the > > > same > > > > type as bead X. > > > > </div> > > > > > > > > In that situation dynamically instantiated component 2 will take > bead X > > > and > > > > we will end up with above situation. Does that valid scenario for > you? > > > > > > > > Thanks, > > > > Piotr > > > > > > > > On Sun, Jan 27, 2019, 10:19 AM Yishay Weiss <yishayj...@hotmail.com > > > wrote: > > > > > > > >> Can you explain why this is necessary? Why create a strand with > bead X > > > and > > > >> replace it with bead Y in runtime? > > > >> > > > >> If your strand is using loadBeadFromValuesManager() it should be > able > > to > > > >> receive a null css class reference, like in this example. > > > >> > > > >> https://github.com/yishayw/Examples/tree/RunTimeLayout > > > >> > > > >> > > > >> From: Carlos Rovira<mailto:carlosrov...@apache.org> > > > >> Sent: Sunday, January 27, 2019 10:26 AM > > > >> To: dev@royale.apache.org<mailto:dev@royale.apache.org> > > > >> Subject: Problems dealing with bead substitution in Royale > > > >> > > > >> 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 > > > >> http://about.me/carlosrovira > > > >> > > > >> > > > > > > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira > -- Carlos Rovira http://about.me/carlosrovira
