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 05:45:27 GMT
Ok. I'm totally willing to believe you and to think that I'm missing
something here but I think you have to explain that a little bit more. What
kind of apps were these? Were they super detailed subcomponents? Or was a
combobox something that needed an item renderer? What other UI set are you
comparing them with?

Or to put a hard number on it how big were these projects? Two people? ten?
or more?

I will admit straight out that most projects that I've worked on had one
Java or Coldfusion guy, one db guy, myself and if we were lucky, a part
time graphic designer.

But I just spent 18 months getting very familiar with the spark
architecture and an old app that we wrote 6 years ago with mx components
has just had some major new features added to it and I'm amazed at how easy
it has gone with the exception of design view in 4.6 totally not working
with a 3.2 code base.

I remember that it was a pain to try and figure out what was a style what
was a skin, etc. - there were a lot of properties to keep track of. That
part was definitely trouble.

But point me to a better set of standard ui components and make the case
for them, because then we can emulate them. I've used a lot of ui
components and these were the best in many ways that I can think of. How
did you like awt or swing or the microsoft native component sets? Did you
use the silverlight components at all?  Tcl did the job?

Did spark solve your problems? Please tell me how removing the ability to
change simple things like label positioning and styles, base colors,
enabled something to solve your problems?

Things can always be better, but what then, in your mind is the gold
standard that we should strive for? Because in my experience, the mx
components were the best out of the box stuff that I've been able to work

The sole caveat was that it was such a mish mash of css, native vectors and
embeded images that it was tough to figure out which way to go to for a
particular idea. But that's practically a documentation issue really.

You had to recompile the whole sdk to add minimal functionality?

Please elaborate.

But more importantly point us to the promised land because I'm obviously
missing some horizon here that I need to know about.

On Thu, Mar 1, 2012 at 11:18 PM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:

> >the mx components were very well designed and complete and (though
> complicated) hit a nice sweet spot between many trade-offs.
> I do agree that it was often about what types of apps you were building,
> however, just to provide another perspective, the mx components were
> neither well designed nor anywhere near a sweet spot for the apps I was
> building. They were clunky, bloated, untestable messes that required
> copying and pasting gobs of code or recompiling the whole SDK to add
> minimal additional functionality. Every day we had to invoke an escape
> hatch to do the work we needed.

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