On 2/28/12 3:56 PM, "Daniel Reicher" <danreic...@gmail.com> wrote:
> 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?
Because we are being asked to work via the "Apache Way" and my understanding
of it says that all discussions happen on this list.
>
> 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.
That's fine, just have the discussion on this list, and put the results in
the code and documentation you check in.
>
> 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"?
The community will say all of those things, on this list. It will come in
the form of a response to a commit email, or as feedback to a patch you
submit, or as a reply to something you post on this list.
>
> 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.
Those who care about consistency will comment on your code if they find
inconsistencies, or make changes themselves. You don't have to get
agreement on your ideas before writing code. In many cases it is better to
write it and get it to work first. It reduces the amount of conjecture.
And there are often surprises when you try to commit a plan to code so
trying to get consensus on a plan and then making a change and getting
consensus again is less efficient than making the changes required to making
it work and then getting comments.
>
> 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?
All good questions best answered by reviewing and using the actual code.
>
> 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.
There is a difference between checking something in and having it go in the
release. The community cares enough about Flex to make sure things are
pretty well vetted before it goes in the release. But we have whiteboard
areas where code goes in so there is less ambiguity about what someone is
saying or what they will or will not do.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
