> > I agree with Alex on this one. Now we may want to vet APIs before they > get into the main SDK / release and that is what the voting process is for. > But, I wouldn't force anyone into a pre-discussion before they start > building anything. I want them to build it for what they need, donate it, > and then we can figure out if it needs to be tweaked or whatever. > > Who said anything about "force"? I don't think anyone should be forced to do anything before coding and one path to inclusion should certainly be - "let coders code" and the community can figure out what to do with it later. That said, why preclude other paths?
I've read through discussions about every bit of minutia and every "pie in the sky" idea for Flex going forward, so I'm not fully understanding the resistance to having a path for building a component with a deliberate goal in mind that serves the needs of the overall community and not just my needs. It, frankly, seems entirely too arbitrary for my tastes. If I, as a developer, want to contribute to the community what is wrong with asking the community for some direction and codifying the results of that discussion so that there is at least an attempt to standardize things work "as expected" for the vast majority of Flex developers who have never and will never look at the underlying source code - they just expect components to behave in a fashion similar to every other component. With the new skinning architecture the distinction on what should be exposed as a CSS property, what should be exposed as a class property and what should be a SkinPart and what should just be coded in to the skin directly can get a little muddied. Additionally, when should something in a skin rely on an event, when should it be bound to a hostComponent property and when should it reach in to the hostComponent and read something during a validation cycle? The different paradigms used for desktop and mobile skinning makes this whole situation even more cloudy as does the multitude of ways to "draw" and where that should happen. Why not as a community say "this is the expectation for component X" and, moreover, "these are the components that should be in the core SDK"? Nothing has to be hard and fast but I certainly have my ideas on what goes where and I'm sure it varies to a large degree across the community. Why not try and keep that to a minimum to make Flex as approachable to developers as possible? Unfortunately, that takes some forethought and coordination. The alternative is to devolve into a loose set of built in components that are all skinned/themed/utilized in varying ways. I've built many components to suit my own needs or scratch my own itch. They work fine in that context. In order to elevate them to use by the greater community would require an additional magnitude of work - work I'd be happy to do if the end goal was a little less subjective. I think there should be a barrier to entry for adding new components to the SDK: Does it belong in the core set or should it be in a secondary library? Is it skinnable? Does it use best practices for how an end developer would expect to use it? Does it meet quality standards? Is it documented sufficiently? Does it meet the needs that a component of its nature would be expected to meet? Is it testable? Is it performant? Absent any goal or even direction who determines if these things are met? You? Me? Put it to a vote? Iterations/improvement can happen after a minimum standard has been met but a minimum standard has to be decided on or it is the wild west and that to me would be deadly to Flex which, at least currently, owes much of its success to being an excellent platform with a full set of quality components to build applications from. I, for one, hope that is preserved or this community will never grow from what it is today.
