Many Thanks Peter, that was of much helpful :) 2016-12-14 16:16 GMT+01:00 Peter Ent <[email protected]>:
> My experience with bead-writing is that if your bead has no dependencies > on other beads, then doing your set up in the strand-setting is the > easiest. > > If your bead needs to know another bead exists, typically a view bead, > then in the strand-setter, ask for that bead using strand.getBeadByType(). > If it comes back, then you are good to proceed, but if you get null, then > set up an event listener for viewChanged (or whatever event makes sense > for you). Then in the deferred setup, continue as you would now that the > bead you seek is present. > > You don't know - or should not assume to know - the order beads are added > to their strand. For that reason, I think beads should do as much as > possible in their strand-settings and if there are dependencies, wait for > all the beads to be added and then complete the set up. > > The other tricky part, especially for view beads, is to know when the size > of anything is true. For the JS side, this is known earlier, just after an > element is displayed; it might not be the final size, but you should have > a valid size. The SWF side is often 0x0 until a couple of rendering passes. > > For this reason, setting up a sizeChanged event listener is important in > view beads and in that function you can lay out component elements in the > strand's space. > > Its not 100% perfect yet, but its getting there. > > ‹peter > > On 12/13/16, 6:32 PM, "Alex Harui" <[email protected]> wrote: > > > > > > >On 12/13/16, 1:14 PM, "[email protected] on behalf of Carlos > Rovira" > ><[email protected] on behalf of [email protected]> > >wrote: > > > >>Hi Alex, > >> > >>I'm trying to get a mental picture of the overall structure, events and > >>when to expect to have data. > >>As you see, my problem with data was in item renderers. I see I have > >>available in set data method (overriding it). > >>Maybe in others components I don't have problem right now. > > > >You can override set data(), or in MXMLItemRenderer there is now a > >dataChange event. The override is more efficient, but dataChange might be > >easier to work with. > > > >IMO, there will be fewer events because we don't have to stop to let the > >player render. Events were important in asynchronous code, but in the > >browser, you can just run code that updates the UI and it generally > >happens immediately. > > > >The LifeCycle is much simpler: Instantiate, (optionally set properties), > >addChild. On addChild, lots of things happen in the child's > >addedToParent: some default beads get placed on the strand, the element is > >placed in the DOM causing styles to be rendered by the browser. But then > >the component should be done, and some components send out an initComplete > >event. > > > >> > >>Another scenario I'm dealing with are beads, it seems we can do all > >>things > >>in set strand method, but not in getter/setters. the next step in MDL > >>library, now that we have the right HTML structure created, is check that > >>events and changes are working right. This right now is not true in the > >>global set, and would be the next thing to do. For example, the click in > >>buttons is working, but as we see the slider was not dispatching the > >>valueChanged event (then Peter fixed it in HTML and as I have some time > >>I'll come back to MDL slider). > > > >Beads have a different lifecycle, but it is similar: Instantiate, > >(optionally set properties), addBead. On addBead, the strand setter is > >called, that's a good time to do most work because the host strand should > >be in the DOM at that point. > > > >If that's not a good time, then you have to listen for some events. There > >might be more events needed, but we aren't dispatching very many > >"just-in-case" events. Again, in PAYG, you should be able to replace any > >instance with an instance that dispatches a useful event. > > > >HTH, > >-Alex > > > > -- Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com http://www.avant2.es Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
