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 Tue, 24 Jan 2012 07:05:32 GMT
Hi Tink,

with all the feedback I've got, I'm now thinking that we should make
behaviors out of things that can be considered secondary, like scrolling,
mouse input, re-sizing, tool-tip (and all your list). A good way would be
to separate core aspects from secondary ones and those extras to become

However, I think this will start a new debate : what's core and what's not.

Also, I agree with removing the need for Skinnable components to be

Best regards,

On Tue, Jan 24, 2012 at 12:32 AM, Tink <> wrote:

> On 23 Jan 2012, at 17:08, Bogdan DINU wrote:
>  Hey Jonathan,
>> I'm convinced about my idea. However, I cannot start developing while I
>> don't have the whole picture, a plan and a road map. And having a whole
>> picture is everything. Look at how Doug challenged me as Devil's advocate
>> :)
> A bit of planning before developing wouldn';t go a miss, so maybe we could
> start with what you would remove from UIComponent and replace with a
> behavior and why (i.e. what components don't require the behavior), as Doug
> said it would be pointless doing all the work to always implement the
> behaviours. I can think of a few
> 1. Styling - The core containers really need any styling. Styling is very
> rarely used in the case of Groups.
> 2. Focus - Only low level components require focus. Containers,
> application views, and complex composite components generally don't need to
> handle focus, just lets their children handle it.
> 3. Validation - Only input controls generally require validation.
> 4. States - I generally only try and use states in skins, although I do
> use them elsewhere, if there is a significant amount of overhead added to
> Groups etc when I'm not using them I'd rather them be removed by default,
> with the ability to add the behavior. Not sure how this would be handled in
> Anything else you'd add to the list?
> I know I have mentioned this before, but removing the need for Skinnable
> components to be DisplayObjects surely would reduce overhead significantly,
> although agreed would reduce the large amount of code in UIComponent.
> Tink


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