Don't if what I want to propose is what others came above but hope that helps:
What about add ALL beads first and then process all beads? If code that setup the bead is run when we have all in the array, the "getBead" method would work. Then make a queue and we could have a "isSetUp", if requested bead was not setup could go to the end of queue and process the following and so until all is processed Don't know if what I'm propossing is absurd or not in the actual ARQ of strand-beads, but I think that some kind of process like this that ensures the order is not important would enhance the concept of beads a lot. Thanks 2016-12-16 16:58 GMT+01:00 Alex Harui <[email protected]>: > You are welcome to start another component set with the overhead to not > care about order. For me, order matters sometimes as does making sure you > set the right booleans in the right order as parameters to a function like > addEventListener or Event's constructor. Documentation can handle most of > this so you don't pay the price at runtime. > > We also have the option of creating debug-mode beads. These beads can > have extra code to detect problems in development then have more > streamlined versions for production. A debug-mode ClippingViewport could > see if anyone calls any of its APIs and if not, spit out something that > says it nobody used it. > > -Alex > > On 12/16/16, 2:33 AM, "Yishay Weiss" <[email protected]> wrote: > > >I checked [1] and > > > > > > > > <js:List id="myContainer1" > >y="20" x="20"> > > > > <js:beads> > > > > > ><js:ListView/> > > > > > ><js:ClippingViewport/> > > > > </js:beads> > > > > </js:List> > > > > > > > >Does behave differently than > > > > > > > > <js:List id="myContainer2" > >y="20" x="120"> > > > > <js:beads> > > > > > ><js:ClippingViewport/> > > > > > ><js:ListView/> > > > > </js:beads> > > > > </js:List> > > > > > > > >Personally, I find this confusing. I think if we can avoid dependency on > >order it’s better. We can either go with Peter’s suggested BeadBase, or > >simply stress in documentation that loading partner beads on set bead() > >is discouraged. > > > > > > > >This [2] is even worse in my opinion. The scrolling viewport doesn’t get > >loaded at all, because titlebar loads the view, which loads the viewport > >before it’s been specified. > > > > > > > >[1] https://paste.apache.org/KJYg > > > >[2] https://paste.apache.org/JU94 > > > > > > > > > > > >From: Alex Harui<mailto:[email protected]> > >Sent: Thursday, December 15, 2016 7:38 PM > >To: [email protected]<mailto:[email protected]> > >Subject: Re: [FlexJS] About Component Cycle and Events > > > > > > > > > >On 12/15/16, 12:01 AM, "Yishay Weiss" <[email protected]> wrote: > > > >>I see your point about overrides. It looks like set strand() is not the > >>place to load partner beads. If that’s the case, is it a bug that > >>ContainerView.strand calls createViewport() which loads the model and the > >>viewport? > >> > > > >I purposefully chose terms like beads and strands because order matters, > >otherwise I probably would have chosen something like rice and nigiri. If > >you plan to override the Viewport, you have to put it on the strand first. > > Beads specified in MXML are loaded before View beads. So the strandutils > >code is useful in many cases in a strand setter, but not all and I think > >you will need to use an event to know when to run it. > > > >-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.
