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 <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 > > > -- http://www.badu.ro
