incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Haykel BEN JEMIA <hayke...@gmail.com>
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
Tink):

public class UIComponent extends FlexSprite
    implements IAutomationObject, IChildList, IConstraintClient,
    IDeferredInstantiationUIComponent, IFlexDisplayObject, IFlexModule,
    IInvalidating, ILayoutManagerClient, IPropertyChangeNotifier,
    IRepeaterClient, IStateClient, IAdvancedStyleClient,
IToolTipManagerClient,
    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

Haykel

On 23 January 2012 23:32, Tink <flex@tink.ws> 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
> MXML.
>
> 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
>
>
>

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