incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cortlandt Winters <c...@cortwinters.net>
Subject Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Date Fri, 02 Mar 2012 04:02:21 GMT
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 <bigosmallm@gmail.com> wrote:

> 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