Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of sebpatu.flex@gmail.com
 designates 74.125.82.43 as permitted sender)
Received-SPF: pass (google.com: domain of sebpatu.flex@gmail.com designates
 10.216.135.106 as permitted sender) client-ip=10.216.135.106;
Message-ID: <4F535E86.3000302@gmail.com>
Date: Sun, 04 Mar 2012 13:22:30 +0100
From: =?ISO-8859-1?Q?s=E9bastien_Paturel?= <sebpatu.flex@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: flex-dev@incubator.apache.org
Subject: Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
References: 
 <CAEFz_vuNuXuoJ3fMFmfGExutGy4T_8u9bUfBxQBkhsfHmdW9aw@mail.gmail.com>
 <CACK5iZdayrjjAQP3fAd2jW-yx-2hbPDcj24GdX_vBr9Tc_6L2A@mail.gmail.com>
 <CAOj8ovyJ7Mw=svtYBk9_OW10rbjer9bAsFRSyUCUpeMJJFrusA@mail.gmail.com>
 <EB6F7A48D477254EAB8F675582F80CD71353EB@DPSBS1.digitalprimates.local>
 <CAOj8ovyahNjqs18z-BZJsGT=EB3-c64qxsxgsCKPihCsOUCzmQ@mail.gmail.com>
 <EB6F7A48D477254EAB8F675582F80CD7135848@DPSBS1.digitalprimates.local>
 <CAOj8ovwumvydZt0Onyq1Yc1wDPbRGSJXa-th_zMCYYRk7Mc98w@mail.gmail.com>
 <CACK5iZf2QsK4uSHXVHb+bV1WdaYv1YZFt47Vi2s6+x6yA8F17A@mail.gmail.com>
 <4F51FC95.6000204@gmail.com>
 <CAOj8ovxb4-7J+qiSzBPayiDKa78uH7CdTngEoQNXyNsy=Kj_wg@mail.gmail.com>
 <B5C17BFB-0694-4E16-AC3E-EA706DB8C8E6@gmail.com>
 <CANcBHECnpYBObWOn6Hd_WZ01qHBs1vuB_OtE+HZMXLBvzub+oQ@mail.gmail.com>
In-Reply-To: 
 <CANcBHECnpYBObWOn6Hd_WZ01qHBs1vuB_OtE+HZMXLBvzub+oQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

When you say that it is the plan, you mean that its already planned to 
take it in the Apache Flex roadmap? Would be great news for MX easy 
skinning lovers.

By the way, where can we find the results of every ideas that decision 
board has put aside for later votes, after all those rich discussions 
from ML?

About the BorderContainer Idea, its one way to do so, but if i 
understand well how it is done, BorderContainer is only a 
SkinnableContainer with styles properties exposed, and for which the 
default skin class use the host component skin properties values with 
code like: contentGroup.setStyle("styleProperty", 
hostComponent.styleProperty);
am i right?

Thats a quite easy solution that would not take much work to achieve.
2 things bothers me:
- Is it a problem if with that solution we need to maintain this easy 
skinning component skin class in sync with the updates of the base 
component skin? (maybe not)
- More important: It means that we also need to define those custom 
skins from a copy of mobile skins?

Would it be possible to use inheritance of skin classes in such a 
purpose instead of starting from a copy of the base skin class? Why 
Adobe did not use this solution for BorderContainer ?

Even better: would it be possible that the component, after init, acces 
its current skin (default Spark, custom, or MOBILE !!) and set the 
exposed values to the skin, overriding the current skin values? Maybe 
the skin class, especially for mobile, could decide if some skin 
settings should not be allowed to be overriden like this?


Le 04/03/2012 07:02, jude a �crit :
> That's the plan (loosely). A set of core components and then convenience
> components.
>
>
> On Sat, Mar 3, 2012 at 3:20 PM, Rob Sheely<robsheely@gmail.com>  wrote:
>
>> Maybe we can build on the concept of the Spark BorderContainer (quoting
>> the docs):
>>
>> The BorderContainer container provides a set of CSS styles and class
>> properties to control the border and background of the container.
>>
>> A set of subclassed Spark components with CSS styling implemented. Or more
>> specifically, a set of skins for the components that expose many properties
>> for CSS styling.
>>
>>