Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of flex.programming@gmail.com
 designates 209.85.210.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <C2D878E5-88D2-4C03-A334-7697A1320973@tink.ws>
References: 
 <CAOD3zvnXwopEjCnaX_ssUgFQy9a1hAU=qacgOnDdaEsWedK=Wg@mail.gmail.com>
	<CAAd0WrbLPo=dO9a=gjqwxkbPMfTijSfks7UxjEpBRLf4EpQNnw@mail.gmail.com>
	<CAOD3zvmrAR_2-cuZKkiS60XFG=VaQm2F1L8VcHWNS9YVoE95=w@mail.gmail.com>
	<C2D878E5-88D2-4C03-A334-7697A1320973@tink.ws>
Date: Tue, 24 Jan 2012 09:05:32 +0200
Message-ID: 
 <CAOD3zvmJ7+LnQWB1ER64+JS+DA2upftdtSjABMCaMSwrLfxcAQ@mail.gmail.com>
Subject: Re: Flex 5 UIComponent - Behavior Pattern
From: Bogdan DINU <flex.programming@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae9340c59e793dc04b740c597

--14dae9340c59e793dc04b740c597
Content-Type: text/plain; charset=ISO-8859-1

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
behaviors.

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
DisplayObjects.

Best regards,
Bogdan

On Tue, Jan 24, 2012 at 12:32 AM, 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
>
>
>


-- 
http://www.badu.ro

--14dae9340c59e793dc04b740c597--