incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Haykel BEN JEMIA <>
Subject Re: Flex 5 UIComponent - Behavior Pattern
Date Tue, 24 Jan 2012 18:09:17 GMT
Just looking at the interfaces UIComponent implements I can see some
candidates for implementation as behaviors (besides the ones suggested by

public class UIComponent extends FlexSprite
    implements IAutomationObject, IChildList, IConstraintClient,
    IDeferredInstantiationUIComponent, IFlexDisplayObject, IFlexModule,
    IInvalidating, ILayoutManagerClient, IPropertyChangeNotifier,
    IRepeaterClient, IStateClient, IAdvancedStyleClient,
    IUIComponent, IValidatorListener, IVisualElement

   - Automation: required only for testing and in special cases
   - Deferred instantiation: not sure about this, but perhaps this could be
   attached by containers that support deferred instantiation of children
   - Repeater client: I personally never use repeaters


On 23 January 2012 23:32, 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