incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reynolds, Brian J (Brian)" <>
Subject Re: Component creation workflow
Date Tue, 28 Feb 2012 00:35:45 GMT
+1 on this idea - I like the concept of having a place to talk about
components and gauge interest.

On 2/27/12 3:24 PM, "Daniel Reicher" <> 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:
> 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?
>using our ProgressBar example, should mx.controls.ProgressBarMode be
>avoided even if that avoidance only entails creating a Spark equivalent:
>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?

View raw message