UIComponent lifecycle and invalidation in FlexJS

[Carlos Rovira <ca...@apache.org>]

I ask it some time ago and I think it was not taken into account, but I
think it's important.

Right now FlexJS brings lots of new concepts like strands and beads or new
mxml "on the fly" but I don't see old but good techniques of legacy Flex 4.
One legacy thing I like was UIComponent lifecycle and it's invalidation
mechanism. I assume that maybe it's too soon and until now nobody tried to
implement this.
But I want to ask since maybe Alex, Peter and others does not want such
lifecycle for UIComponents.

I think we should discuss a bit about what we want in this section and if
we could plan to have something in the line of what we already have in Flex
or people are considering new approaches.

Re: UIComponent lifecycle and invalidation in FlexJS

[Carlos Rovira <ca...@codeoscopic.com>]

I see the point. I think JS version could live without invalidation, as I
think this was always its nature, but SWF version maybe not...as you said
maybe it's better to see how far can we reach without this lifecycle.

In Flex 4, for displaylist invalidation and components visuals redraw,
users need less traditional techniques since we have skins and FXG. I mean,
I need rarely to override updateDisplayList (but sometimes is needed, and
it end happening at skin level...). I'm talking of desktop/browser flex
since mobile is 100% programatic skinning. As you point measurement is even
less rare and even component developers could get his work done without
implement a measurement method in this component.

The invalidating properties is needed since ordering is important and in
component development 100% of times you need to make properties, and
override commitProperties method to make things happen in the right time
and in the right order. So in my experience, this should be needed.



2013/6/8 Alex Harui <ah...@adobe.com>

>
>
> On 6/7/13 3:15 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> >I ask it some time ago and I think it was not taken into account, but I
> >think it's important.
> >
> >Right now FlexJS brings lots of new concepts like strands and beads or new
> >mxml "on the fly" but I don't see old but good techniques of legacy Flex
> >4.
> >One legacy thing I like was UIComponent lifecycle and it's invalidation
> >mechanism. I assume that maybe it's too soon and until now nobody tried to
> >implement this.
> >But I want to ask since maybe Alex, Peter and others does not want such
> >lifecycle for UIComponents.
> >
> >I think we should discuss a bit about what we want in this section and if
> >we could plan to have something in the line of what we already have in
> >Flex
> >or people are considering new approaches.
>
> Good topic as well.  Right now, I want to see how far we can go in FlexJS
> without invalidation.  That's because current Flex relies on frame events
> to pump validation and there is no such thing as frame events in HTML/JS
> and I'd rather not keep hooking up to setTimeout.  But that is not set in
> stone either.
>
>
> In fact, Peter and I were discussing this topic in relation to the Alert
> classes he is building as he needed to measure some text.  It turns out
> that the measuring phase in current Flex is not always useful and
> sometimes wasteful.  Currently Flex measures every component on the
> display list from the bottom up, but quite often, layout is driven from
> the top by percentages and other constraints and the measurements are not
> needed up front.
>
> FlexJS is attempting to do more things "on-demand" so instead of measuring
> everything, we're going to see if we can get away with measuring only when
> we need to.
>
> Invalidation is good when changing a bunch of properties at once,
> especially when properties needed to be applied in a certain order.  The
> question is whether that needs to be handled globally like a LayoutManager
> or some more internal callLater feature on a per-instance basis.
>
> Like I said, nothing is set in stone, so thoughts on this topic are
> welcome.
>
> -Alex
>
>


-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Re: UIComponent lifecycle and invalidation in FlexJS

[Alex Harui <ah...@adobe.com>]

On 6/7/13 3:15 PM, "Carlos Rovira" <ca...@apache.org> wrote:

>I ask it some time ago and I think it was not taken into account, but I
>think it's important.
>
>Right now FlexJS brings lots of new concepts like strands and beads or new
>mxml "on the fly" but I don't see old but good techniques of legacy Flex
>4.
>One legacy thing I like was UIComponent lifecycle and it's invalidation
>mechanism. I assume that maybe it's too soon and until now nobody tried to
>implement this.
>But I want to ask since maybe Alex, Peter and others does not want such
>lifecycle for UIComponents.
>
>I think we should discuss a bit about what we want in this section and if
>we could plan to have something in the line of what we already have in
>Flex
>or people are considering new approaches.

Good topic as well.  Right now, I want to see how far we can go in FlexJS
without invalidation.  That's because current Flex relies on frame events
to pump validation and there is no such thing as frame events in HTML/JS
and I'd rather not keep hooking up to setTimeout.  But that is not set in
stone either.


In fact, Peter and I were discussing this topic in relation to the Alert
classes he is building as he needed to measure some text.  It turns out
that the measuring phase in current Flex is not always useful and
sometimes wasteful.  Currently Flex measures every component on the
display list from the bottom up, but quite often, layout is driven from
the top by percentages and other constraints and the measurements are not
needed up front.

FlexJS is attempting to do more things "on-demand" so instead of measuring
everything, we're going to see if we can get away with measuring only when
we need to.

Invalidation is good when changing a bunch of properties at once,
especially when properties needed to be applied in a certain order.  The
question is whether that needs to be handled globally like a LayoutManager
or some more internal callLater feature on a per-instance basis.

Like I said, nothing is set in stone, so thoughts on this topic are
welcome.

-Alex