+1 on this idea - I like the concept of having a place to talk about components and gauge interest. Brian
On 2/27/12 3:24 PM, "Daniel Reicher" <danreic...@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?
