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: local policy)
From: "Reynolds, Brian J (Brian)" <reynolds@avaya.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Mon, 27 Feb 2012 19:35:45 -0500
Subject: Re: Component creation workflow
Thread-Topic: Component creation workflow
Thread-Index: Acz1sOaCfAZqSIoBThedJlJv9c1UDw==
Message-ID: <CB716EE5.14E03%reynolds@avaya.com>
In-Reply-To: 
 <CAE0mPOsG+TQ-u2oPWL_skkQiMQLkL4K-fd7d_9W3pMvD+fHuhg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

+1 on this idea - I like the concept of having a place to talk about
components and gauge interest.
 =20
Brian=20


On 2/27/12 3:24 PM, "Daniel Reicher" <danreicher@gmail.com> wrote:

>I've seen pockets of discussion regarding component creation but nothing
>formalized (it seems) and I think it might be useful to have some process
>in place - even a loose one. For the purpose of opening a discussion, I'll
>use a mythical ProgressBar component...
>
>Is there a place in the wiki currently or could one be created to handle
>the architecture of component proposals? Adobe maintained one (example:
>http://opensource.adobe.com/wiki/display/flexsdk/Spark+NumericStepper) and
>that seems like a decent jumping off point. It seems that there would be
>immense value in codifying discussions to a page like this so that a
>generally agreed upon approach can be worked. This, at least, gives some
>idea to the scoped functionality of the component and some idea to what
>belongs where. As an example, with our fictional ProgressBar, should the
>indeterminate overlay be a SkinPart or should it be exposed as css styles:
>indeterminateOverlayColor, indeterminateOverlayAlpha,
>indeterminateOverlayWidth, indeterminateOverlayGap, etc.? What should the
>base class be: SkinnableComponent, Range, etc.? What events should be
>dispatched? What do the default SkinnableComponent css properties
>(chromeColor, contentBackgroundColor, etc.) affect?
>
>Is there a list tag for discussing implementation/architecture for a
>specific component or piece of functionality?
>
>Is the current "group think" to continue the component, MXML Spark Skin,
>code-based/optimized Mobile Skin architecture?
>
>How closely should a Spark component that has an mx equivalent adhere to
>the functionality of the mx component?
>
>Should spark components have clean separation from the mx namespace?
>Again,
>using our ProgressBar example, should mx.controls.ProgressBarMode be
>avoided even if that avoidance only entails creating a Spark equivalent:
>spark.controls.ProgresBarMode?
>
>Should components be "allowed" to be mobile-only or desktop-only or should
>everything be available in both scenarios unless there is an extremely
>overwhelming rationale not to?