On Thu, Mar 1, 2012 at 3:12 PM, Omar Gonzalez <omarg.develo...@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
