flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Reicher <danreic...@gmail.com>
Subject Component creation workflow
Date Mon, 27 Feb 2012 22:24:43 GMT
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:

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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message