flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Reicher <danreic...@gmail.com>
Subject Re: Component creation workflow
Date Tue, 28 Feb 2012 23:56:57 GMT
>  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.

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