Actually this is a very good question and I think that folk have many different opinions. Often based on the kinds of apps that they work on or the kind of work that they do.
While I have no true window into the motivation, I believe that the motivation of the spark component set is two fold. The first is to provide a cleaner separation between visual appearance and core functionality. I think the second was to support declarative visual tooling. From a high level I think Adobe hit the nail on the head about what was needed but was unable to come up with the implementation to fit the vision. Spark seems, from a programmers standpoint, a better architecture from mx, but it may be too formal and strict given the fact that it took so long to create the spark components and the fact that there are still no complete skins that anybody has created for them. I really don't know as I'm not that clued into the design shops. the mx components were very well designed and complete and (though complicated) hit a nice sweet spot between many trade-offs. It's easy to be very productive with the mx components in a small team without tooling. In many cases simple things like changing the color of a scrollbar or the layout of a label or the height of a part of a component was covered with the mx components, and was left as a "reader exercise" in the spark ones. For those of us who have applications out in the wild with mx components it would be terrible for them to be depreciated. I doubt if the spark components, despite their theoretical strengths will ever hit the sweet spot of what folk want out of a component like the mx ones did. Having said that the spark architecture has already shown that it will certainly be the way to go for components that have one appearance on an Iphone, another on an android and another in the web app. So it or a simpler version of it is clearly the way going forward. The plan at this point I think is to do new component development with the spark architecture and try to use the skinning flexibility to target android devices with android skins and ios devices wtih ios skins, web apps with a web skin, desktop apps with os specific ones. Wait for adobe to put out the key missing ones. Companies that want to make their transition from mx to spark and tablets or phones easier should try to contribute spark skins that make the transition easier for each other. It is ok to have two totally different component sets. A legacy one and a new one. Those of us who have had to go through transitioning apps from one to the other could eventually offer direction and advice to those who would like to but are afraid to because of the wildly different feature sets. I understand Alex's desire to redo the spark architecture to something that goes for a totally new and simpler sweet spot. And I think that after v5 that should be a core goal for folk, but the spark architecture doesn't seem that bad to me and there are a lot of apps out there using the mx one, which is why I think that providing a clear transition path is well worth it if there are folk that are willing to do the work. If we had the workers to put together a whole new component set that utilized the gamut of experience in building components I'm sure we could do a great job, but not in time for v5. I'm totally willing to say that I'm wrong if there is some cohesive vision that shows how we could just do a simpler version of spark, hit the necessaries with v5 and then migrate from mx to the new architecture instead of spark, but I am not capable at this point of figuring out what that other thing should be, so that may be a blind spot. One that I'm willing to fix. I just need to hear and learn more about that vision. On Thu, Mar 1, 2012 at 6:25 PM, Om <bigosma...@gmail.com> wrote: > 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 >
