incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bogdan DINU <>
Subject Re: Flex 5 UIComponent - Behavior Pattern
Date Mon, 23 Jan 2012 09:53:35 GMT
Hi Giorgio,

by having separate classes for dealing with specialized behaviors, I think
UIComponent will become very flexible and instead of extending UIComponent
we would just add certain behaviors to it, composing rather than extending.

Benefits :

1) maintaining inheritance with older versions of SDK while writing an
entirely new framework;
2) lightweight components based on UIComponent;
3) lightweight jobs for sdk managers;
4) smaller memory foot print compared to previous versions;
5) high customization of components for advanced developers while
benefiting of inheritance in order for new comers to use existing tutorials
(of course, until new documentation will be created);
6) much more clear logic and understanding of components lifecycle;
7) provides a powerful new way of including other frameworks to the sdk
(example : let's say that you totally override a behavior class, in order
to make use of injections in the entire framework).

Probably there are more benefits that I couldn't think about now - will get
back to the subject if something comes to my mind.

Regarding trains, I think there is no resemblance. But if you have an idea
on how to achieve that with traits, I'm interested!

Best regards,

On Mon, Jan 23, 2012 at 11:39 AM, Giorgio Natili <>wrote:

> Hi Bogdan,
> In your post you refer to this implementation as useful from an
> accessibility point of view, can you clarify what do you mean exactly and
> which are the benefits you see in this field?
> You don't thing the pattern you described is very similar to traits?
> Giorgio
> On 1/23/12 9:32 AM, "Bogdan DINU" <> wrote:
> >Hi everybody,
> >
> >I have a suggestion regarding how Flex 5 UIComponent class should work.
> >Please read this <> and
> >this<>in order to understand what I mean.
> >
> >I think that this approach will solve not only the compatibility issues
> >that we might encounter, but also automation (besides many many other
> >things), create lightweight and powerful components with less memory usage
> >and add a very flexible way to create new components.
> >
> >I've seen this technique is often used in games. Saw it implemented in Ben
> >Stucki's Reflex framework <>
> and
> >in Michael's Schmalle
> >tkarchitecture<>
> >.
> >
> >Please let me know if you know any drawbacks that you can foresee.
> >
> >Best regards to you all,
> >Bogdan
> >
> >--
> >


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message