incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Date Thu, 01 Mar 2012 23:25:36 GMT
On Thu, Mar 1, 2012 at 3:12 PM, Omar Gonzalez <omarg.developer@gmail.com>wrote:

> >
> > Maybe, I am completely off base here, but exactly what is the motivation
> of
> > the spark component set?  Is it the new skinning paradigm, or is it
> better
> > performing versions of existing components or is it a completely
> different
> > set of components that happen to have similar names?  If this is a
> separate
> > conversation, please reply in a new thread.
> >
> > Thanks,
> > Om
> >
>
> Personally for me the motivation to create Spark equivalents of some of
> these components is the better skinning model. At least, in my opinion, I
> much prefer the Spark skinning over MX. This is why I haven't done any MX
> apps since Spark came out.
>
>
Right, but why are mx components shipping when equivalent spark versions
are available?  This to me is the biggest sticking point.  Can we nix mx
components from future releases if that is the 'old' way of doing things?

Was the original plan (by Adobe's Flex team) to get to 100% mx <=> spark
parity before nixing mx in a future release?  If yes, can someone explain
the motivations for such a decision?

(Non-rhetorical question) Is everyone okay with different components with
completely different architectures and supporting different sets of
features with the same names shipping alongside in the same SDK?  If yes,
what are the benefits?

Or was the original plan was to support two different sets of components
that support two different skinning architectures?  It does not appear so
from the code hints (Use s:XYZ instead) that appear when we attempt to use
an mx component.

IMHO, we need to pick one plan and make sure that EVERY component we ship
with the SDK follows the same set of rules.

Thanks,
Om

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