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 <f...@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
>
>
>
