You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Carlos Rovira <ca...@apache.org> on 2016/12/11 08:25:47 UTC
[FlexJS] About Component Cycle and Events
Hi,
I open this thread to talk about FlexJS Component Cycle and the supported
events.
we need to know what to expect about :
* When data is available in a component
* we don't have the classic methods like commitProperties,
updateDisplayList,...
* What events do we have? initComplete? creationComplete? and what
components have this: UIBase? MXMLItemRenderer?
Thanks
--
Carlos Rovira
http://about.me/carlosrovira
Re: [FlexJS] About Component Cycle and Events
Posted by Peter Ent <pe...@adobe.com>.
On 12/15/16, 12:33 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 12/15/16, 8:22 AM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>Having done a bunch of these, I'd like to propose something a little
>>controversial.
>>
>>A new class, BaseBead, from which all Beads derive (you can choose not to
>>do this in your custom beads, just implement IBead). BaseBead has:
>>
>>public function set strand(value:IStrand):void {Š}
>>public function get strand():IStrand {Š}
>>
>>public function strandReady():void
>>- your bead class overrides strandReady() which is called by the strand
>>setter function and in your override you set up your bead. If your bead
>>needs to be aware of other beads, override the next function:
>>
>>public function beadsLoaded():void
>>- your bead class, if it needs to, overrides beadsLoaded() and completes
>>it set up. You can use strand.getBeadByType() to look for any other beads
>>your bead might need.
>>
>>I separated the setting of the strand into two functions so that bead
>>authors have a clear path in that they always override strandReady and
>>optionally override beadsLoaded. This would give a consistent pattern to
>>bead loading and allow the underlaying bead framework to be changed in
>>the
>>future. I don't think this will add much overhead to the PAYG plan, and I
>>think it will be easier for developers to know what to do if there is a
>>consistent set of steps to follow. These functions in BaseBead may be
>>minor, but it would save developers from having to do the same thing over
>>and over.
>
>Hmm. Maybe. How would the base class know when and whether to call
>beadsLoaded. Having every bead listen for beadsAdded might add up to
>something.
Yes, that's true. Maybe in strandReady() you set a boolean like
needsToWait which then triggers the BaseBead to set up the event listener.
>
>-Alex
>
Re: [FlexJS] About Component Cycle and Events
Posted by Alex Harui <ah...@adobe.com>.
On 12/15/16, 8:22 AM, "Peter Ent" <pe...@adobe.com> wrote:
>Having done a bunch of these, I'd like to propose something a little
>controversial.
>
>A new class, BaseBead, from which all Beads derive (you can choose not to
>do this in your custom beads, just implement IBead). BaseBead has:
>
>public function set strand(value:IStrand):void {Š}
>public function get strand():IStrand {Š}
>
>public function strandReady():void
>- your bead class overrides strandReady() which is called by the strand
>setter function and in your override you set up your bead. If your bead
>needs to be aware of other beads, override the next function:
>
>public function beadsLoaded():void
>- your bead class, if it needs to, overrides beadsLoaded() and completes
>it set up. You can use strand.getBeadByType() to look for any other beads
>your bead might need.
>
>I separated the setting of the strand into two functions so that bead
>authors have a clear path in that they always override strandReady and
>optionally override beadsLoaded. This would give a consistent pattern to
>bead loading and allow the underlaying bead framework to be changed in the
>future. I don't think this will add much overhead to the PAYG plan, and I
>think it will be easier for developers to know what to do if there is a
>consistent set of steps to follow. These functions in BaseBead may be
>minor, but it would save developers from having to do the same thing over
>and over.
Hmm. Maybe. How would the base class know when and whether to call
beadsLoaded. Having every bead listen for beadsAdded might add up to
something.
-Alex
Re: [FlexJS] About Component Cycle and Events
Posted by Peter Ent <pe...@adobe.com>.
Having done a bunch of these, I'd like to propose something a little
controversial.
A new class, BaseBead, from which all Beads derive (you can choose not to
do this in your custom beads, just implement IBead). BaseBead has:
public function set strand(value:IStrand):void {Š}
public function get strand():IStrand {Š}
public function strandReady():void
- your bead class overrides strandReady() which is called by the strand
setter function and in your override you set up your bead. If your bead
needs to be aware of other beads, override the next function:
public function beadsLoaded():void
- your bead class, if it needs to, overrides beadsLoaded() and completes
it set up. You can use strand.getBeadByType() to look for any other beads
your bead might need.
I separated the setting of the strand into two functions so that bead
authors have a clear path in that they always override strandReady and
optionally override beadsLoaded. This would give a consistent pattern to
bead loading and allow the underlaying bead framework to be changed in the
future. I don't think this will add much overhead to the PAYG plan, and I
think it will be easier for developers to know what to do if there is a
consistent set of steps to follow. These functions in BaseBead may be
minor, but it would save developers from having to do the same thing over
and over.
‹peter
On 12/15/16, 3:01 AM, "Yishay Weiss" <yi...@hotmail.com> 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?
>
>
>
>From: Alex Harui<ma...@adobe.com>
>Sent: Thursday, December 15, 2016 9:30 AM
>To: dev@flex.apache.org<ma...@flex.apache.org>
>Subject: Re: [FlexJS] About Component Cycle and Events
>
>
>
>
>On 12/14/16, 10:25 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>>
>>That was my intent, load it when necessary. My point was that there was
>>no reason to attach event handlers when you need the bead, you can just
>>check for its existence and load it if necessary.
>
>I just took a look at strandutils. Sure it packages up a common pattern
>(check for bead, load bead from values manager), but I'm not understanding
>how it would work if called from within the strand setter. For example,
>if in MXML, someone did:
>
><SomeComponent>
> <beads>
> <SomeBead />
> <AnotherBeadThatWorksWIthSomeBead />
>
>I don't think SomeBead can use StrandUtils. The desired partner bead is
>about to be added to the strand right after SomeBead as an override for
>the default partner bead that would be fetched from ValuesManager. You
>could require that overrides have to be before the other partner bead, but
>some beads are peers and you can't really specify the order.
>
>I think that's why we recommend using an event. Once all beads are added,
>you get an event if you want it, and can get events when beads are added
>"later".
>
>-Alex
>
Re: [FlexJS] About Component Cycle and Events
Posted by Alex Harui <ah...@adobe.com>.
On 12/16/16, 10:14 AM, "carlos.rovira@gmail.com on behalf of Carlos
Rovira" <carlos.rovira@gmail.com on behalf of
carlos.rovira@codeoscopic.com> wrote:
>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.
Fundamentally, assuming order is more efficient that not assuming order.
IMO, it isn't that much harder than remembering the order of the booleans
on the Event constructor. If you have to walk the array twice, once to
add them and once to init them, that is more work than going through it
once. We can provide tooling and debug-mode beads to help you get it
right, but I don't like the idea of making the production version run code
that isn't needed. IMO, not having good optimized production code is one
of the reasons Flex did not get the traction it needed to remain popular.
Folks are welcome to create beads that don't care about order, but the
most Basic beads should since they are trying to be the smallest and
fastest.
-Alex
Re: [FlexJS] About Component Cycle and Events
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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 <ah...@adobe.com>:
> 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" <yi...@hotmail.com> 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<ma...@adobe.com>
> >Sent: Thursday, December 15, 2016 7:38 PM
> >To: dev@flex.apache.org<ma...@flex.apache.org>
> >Subject: Re: [FlexJS] About Component Cycle and Events
> >
> >
> >
> >
> >On 12/15/16, 12:01 AM, "Yishay Weiss" <yi...@hotmail.com> 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.
Re: [FlexJS] About Component Cycle and Events
Posted by Alex Harui <ah...@adobe.com>.
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" <yi...@hotmail.com> 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<ma...@adobe.com>
>Sent: Thursday, December 15, 2016 7:38 PM
>To: dev@flex.apache.org<ma...@flex.apache.org>
>Subject: Re: [FlexJS] About Component Cycle and Events
>
>
>
>
>On 12/15/16, 12:01 AM, "Yishay Weiss" <yi...@hotmail.com> 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
>
RE: [FlexJS] About Component Cycle and Events
Posted by Yishay Weiss <yi...@hotmail.com>.
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<ma...@adobe.com>
Sent: Thursday, December 15, 2016 7:38 PM
To: dev@flex.apache.org<ma...@flex.apache.org>
Subject: Re: [FlexJS] About Component Cycle and Events
On 12/15/16, 12:01 AM, "Yishay Weiss" <yi...@hotmail.com> 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
Re: [FlexJS] About Component Cycle and Events
Posted by Alex Harui <ah...@adobe.com>.
On 12/15/16, 12:01 AM, "Yishay Weiss" <yi...@hotmail.com> 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
RE: [FlexJS] About Component Cycle and Events
Posted by Yishay Weiss <yi...@hotmail.com>.
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?
From: Alex Harui<ma...@adobe.com>
Sent: Thursday, December 15, 2016 9:30 AM
To: dev@flex.apache.org<ma...@flex.apache.org>
Subject: Re: [FlexJS] About Component Cycle and Events
On 12/14/16, 10:25 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>
>That was my intent, load it when necessary. My point was that there was
>no reason to attach event handlers when you need the bead, you can just
>check for its existence and load it if necessary.
I just took a look at strandutils. Sure it packages up a common pattern
(check for bead, load bead from values manager), but I'm not understanding
how it would work if called from within the strand setter. For example,
if in MXML, someone did:
<SomeComponent>
<beads>
<SomeBead />
<AnotherBeadThatWorksWIthSomeBead />
I don't think SomeBead can use StrandUtils. The desired partner bead is
about to be added to the strand right after SomeBead as an override for
the default partner bead that would be fetched from ValuesManager. You
could require that overrides have to be before the other partner bead, but
some beads are peers and you can't really specify the order.
I think that's why we recommend using an event. Once all beads are added,
you get an event if you want it, and can get events when beads are added
"later".
-Alex
Re: [FlexJS] About Component Cycle and Events
Posted by Alex Harui <ah...@adobe.com>.
On 12/14/16, 10:25 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>
>That was my intent, load it when necessary. My point was that there was
>no reason to attach event handlers when you need the bead, you can just
>check for its existence and load it if necessary.
I just took a look at strandutils. Sure it packages up a common pattern
(check for bead, load bead from values manager), but I'm not understanding
how it would work if called from within the strand setter. For example,
if in MXML, someone did:
<SomeComponent>
<beads>
<SomeBead />
<AnotherBeadThatWorksWIthSomeBead />
I don't think SomeBead can use StrandUtils. The desired partner bead is
about to be added to the strand right after SomeBead as an override for
the default partner bead that would be fetched from ValuesManager. You
could require that overrides have to be before the other partner bead, but
some beads are peers and you can't really specify the order.
I think that's why we recommend using an event. Once all beads are added,
you get an event if you want it, and can get events when beads are added
"later".
-Alex
FW: [FlexJS] About Component Cycle and Events
Posted by Yishay Weiss <yi...@hotmail.com>.
From: Yishay Weiss<ma...@hotmail.com>
Sent: Thursday, December 15, 2016 8:24 AM
To: Alex Harui<ma...@adobe.com>
Subject: RE: [FlexJS] About Component Cycle and Events
That was my intent, load it when necessary. My point was that there was no reason to attach event handlers when you need the bead, you can just check for its existence and load it if necessary.
From: Alex Harui<ma...@adobe.com>
Sent: Thursday, December 15, 2016 6:46 AM
To: dev@flex.apache.org<ma...@flex.apache.org>
Subject: Re: [FlexJS] About Component Cycle and Events
On 12/14/16, 1:50 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>On Wed, Dec 14, 2016 at 11:18 AM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 12/14/16, 10:42 AM, "yishayw" <yi...@hotmail.com> wrote:
>>
>>>Is there a reason not to proactively load the beads you need? If you use
>> >org.apache.flex.utils.StrandUtils.loadBead(), you can be assured that
>>the
>> >bead has been loaded and retain a synchronous flow.
>> >
>>
>> IMO, proactive is not PAYG.
>>
>
>I'm a bit confused. How is loading a bead when needed not Pay-as-you-go?
>What is your definition of pay-as-you-go?
I read "proactive" to mean "so far in advance it is just-in-case". Of
course you have to load a bead before you use it, but it should be as
close to on-demand as you can get.
-Alex
Re: [FlexJS] About Component Cycle and Events
Posted by Alex Harui <ah...@adobe.com>.
On 12/14/16, 1:50 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>On Wed, Dec 14, 2016 at 11:18 AM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 12/14/16, 10:42 AM, "yishayw" <yi...@hotmail.com> wrote:
>>
>>>Is there a reason not to proactively load the beads you need? If you use
>> >org.apache.flex.utils.StrandUtils.loadBead(), you can be assured that
>>the
>> >bead has been loaded and retain a synchronous flow.
>> >
>>
>> IMO, proactive is not PAYG.
>>
>
>I'm a bit confused. How is loading a bead when needed not Pay-as-you-go?
>What is your definition of pay-as-you-go?
I read "proactive" to mean "so far in advance it is just-in-case". Of
course you have to load a bead before you use it, but it should be as
close to on-demand as you can get.
-Alex
Re: [FlexJS] About Component Cycle and Events
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Dec 14, 2016 at 11:18 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 12/14/16, 10:42 AM, "yishayw" <yi...@hotmail.com> wrote:
>
> >Peter Ent wrote
> >> 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.
> >
> >Is there a reason not to proactively load the beads you need? If you use
> >org.apache.flex.utils.StrandUtils.loadBead(), you can be assured that the
> >bead has been loaded and retain a synchronous flow.
> >
>
> IMO, proactive is not PAYG. Don't do things just-in-case, do them
> just-in-time. In some future world, we may not load interaction beads
> (mouse handling and keyboard handling) until after the first screen is
> visible. Give the user something to look at, they will need at least
> 250ms to react to it. No need to initialize interaction until there is
> something to interact with, IMO.
>
I'm a bit confused. How is loading a bead when needed not Pay-as-you-go?
What is your definition of pay-as-you-go?
Thanks,
Om
>
> My 2 cents.
> -Alex
>
>
Re: [FlexJS] About Component Cycle and Events
Posted by Alex Harui <ah...@adobe.com>.
On 12/14/16, 10:42 AM, "yishayw" <yi...@hotmail.com> wrote:
>Peter Ent wrote
>> 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.
>
>Is there a reason not to proactively load the beads you need? If you use
>org.apache.flex.utils.StrandUtils.loadBead(), you can be assured that the
>bead has been loaded and retain a synchronous flow.
>
IMO, proactive is not PAYG. Don't do things just-in-case, do them
just-in-time. In some future world, we may not load interaction beads
(mouse handling and keyboard handling) until after the first screen is
visible. Give the user something to look at, they will need at least
250ms to react to it. No need to initialize interaction until there is
something to interact with, IMO.
My 2 cents.
-Alex
Re: [FlexJS] About Component Cycle and Events
Posted by yishayw <yi...@hotmail.com>.
Peter Ent wrote
> 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.
Is there a reason not to proactively load the beads you need? If you use
org.apache.flex.utils.StrandUtils.loadBead(), you can be assured that the
bead has been loaded and retain a synchronous flow.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-About-Component-Cycle-and-Events-tp57153p57258.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] About Component Cycle and Events
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Many Thanks Peter, that was of much helpful :)
2016-12-14 16:16 GMT+01:00 Peter Ent <pe...@adobe.com>:
> 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" <ah...@adobe.com> wrote:
>
> >
> >
> >On 12/13/16, 1:14 PM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> ><carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> >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.
Re: [FlexJS] About Component Cycle and Events
Posted by Peter Ent <pe...@adobe.com>.
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" <ah...@adobe.com> wrote:
>
>
>On 12/13/16, 1:14 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
><carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>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
>
Re: [FlexJS] About Component Cycle and Events
Posted by Alex Harui <ah...@adobe.com>.
On 12/13/16, 1:14 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> 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
Re: [FlexJS] About Component Cycle and Events
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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.
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).
My current work is on InnerHTML bead and this bead is sensible to when code
is executed since it could add the html text first and then other nodes, or
the reverse. But I'll comment this in the InnerThread text better to not
mix things.
Thanks
2016-12-12 6:04 GMT+01:00 Alex Harui <ah...@adobe.com>:
> The Basic component set does not use any invalidation/validation. Mostly
> that is because the underlying HTMLElements don't have the same sort of
> update/render phases like Flash. They are what I call "immediate".
> Other, more sophisticated component sets can implement
> invalidation/validation if they want to. The MX/Spark port POC did, for
> example.
>
> So, because your code typically doesn't have to wait for something to
> happen, I think we require fewer events. More inline...
>
> On 12/11/16, 12:25 AM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> wrote:
>
> >Hi,
> >
> >I open this thread to talk about FlexJS Component Cycle and the supported
> >events.
> >we need to know what to expect about :
> >
> >* When data is available in a component
>
> Not sure what you mean here, are you referring to item renderers? I just
> added dataChange to MXMLItemRenderer, but the other item renderer base
> classes don't dispatch an event.
>
> >* we don't have the classic methods like commitProperties,
> >updateDisplayList,...
> >* What events do we have? initComplete? creationComplete? and what
> >components have this: UIBase? MXMLItemRenderer?
>
> Some components like Container, and List dispatch initComplete. Again,
> because there aren't invalidation phases, it isn't clear that you need
> both initialize and creationComplete events. One event is probably good
> enough, but I could certainly be wrong, so provide more detail about your
> scenario.
>
> Yishay mentions beadsAdded. It really just means all beads have been
> added. There could be other work that happens afterwards before the call
> to addChild returns.
>
> 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.
Re: [FlexJS] About Component Cycle and Events
Posted by Alex Harui <ah...@adobe.com>.
The Basic component set does not use any invalidation/validation. Mostly
that is because the underlying HTMLElements don't have the same sort of
update/render phases like Flash. They are what I call "immediate".
Other, more sophisticated component sets can implement
invalidation/validation if they want to. The MX/Spark port POC did, for
example.
So, because your code typically doesn't have to wait for something to
happen, I think we require fewer events. More inline...
On 12/11/16, 12:25 AM, "carlos.rovira@gmail.com on behalf of Carlos
Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
wrote:
>Hi,
>
>I open this thread to talk about FlexJS Component Cycle and the supported
>events.
>we need to know what to expect about :
>
>* When data is available in a component
Not sure what you mean here, are you referring to item renderers? I just
added dataChange to MXMLItemRenderer, but the other item renderer base
classes don't dispatch an event.
>* we don't have the classic methods like commitProperties,
>updateDisplayList,...
>* What events do we have? initComplete? creationComplete? and what
>components have this: UIBase? MXMLItemRenderer?
Some components like Container, and List dispatch initComplete. Again,
because there aren't invalidation phases, it isn't clear that you need
both initialize and creationComplete events. One event is probably good
enough, but I could certainly be wrong, so provide more detail about your
scenario.
Yishay mentions beadsAdded. It really just means all beads have been
added. There could be other work that happens afterwards before the call
to addChild returns.
HTH,
-Alex
Re: [FlexJS] About Component Cycle and Events
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Thanks Yishay, as I said in a new thread just created that is very useful
to me. :)
2016-12-11 9:37 GMT+01:00 Yishay Weiss <yi...@hotmail.com>:
> We’ve been using the ‘beadsAdded’ event as a ‘creationComplete’
> replacement. This is fired by all UIBase derivatives (including
> MXMLItemRenderer) after they’ve been added to the parent, and all their
> beads have been added. I think the rest of the relevant events depend on
> the component, but Alex will probably have a more complete answer.
>
>
>
> From: Carlos Rovira<ma...@apache.org>
> Sent: Sunday, December 11, 2016 10:26 AM
> To: dev@flex.apache.org<ma...@flex.apache.org>
> Subject: [FlexJS] About Component Cycle and Events
>
>
>
> Hi,
>
> I open this thread to talk about FlexJS Component Cycle and the supported
> events.
> we need to know what to expect about :
>
> * When data is available in a component
> * we don't have the classic methods like commitProperties,
> updateDisplayList,...
> * What events do we have? initComplete? creationComplete? and what
> components have this: UIBase? MXMLItemRenderer?
>
> Thanks
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
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.
RE: [FlexJS] About Component Cycle and Events
Posted by Yishay Weiss <yi...@hotmail.com>.
We’ve been using the ‘beadsAdded’ event as a ‘creationComplete’ replacement. This is fired by all UIBase derivatives (including MXMLItemRenderer) after they’ve been added to the parent, and all their beads have been added. I think the rest of the relevant events depend on the component, but Alex will probably have a more complete answer.
From: Carlos Rovira<ma...@apache.org>
Sent: Sunday, December 11, 2016 10:26 AM
To: dev@flex.apache.org<ma...@flex.apache.org>
Subject: [FlexJS] About Component Cycle and Events
Hi,
I open this thread to talk about FlexJS Component Cycle and the supported
events.
we need to know what to expect about :
* When data is available in a component
* we don't have the classic methods like commitProperties,
updateDisplayList,...
* What events do we have? initComplete? creationComplete? and what
components have this: UIBase? MXMLItemRenderer?
Thanks
--
Carlos Rovira
http://about.me/carlosrovira