flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Labriola" <labri...@digitalprimates.net>
Subject RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Date Fri, 02 Mar 2012 14:36:22 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?

The need to build and extend these components for large enterprises

>Or to put a hard number on it how big were these projects? Two people? ten? or more?
Dozens sometimes hundreds.

>But point me to a better set of standard ui components and make the case for them, because
then we can emulate them. 
Its not that there is a better set. The point is that there are major improvements that can
be made

>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?
Although I didn't always like their internals, the quantity and general extensibility of many
of the Silverlight components was quite nice

>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?
It solves many of the problems simply by delegating the instantiation of the visual components
to a separate, swappable class

>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 with.
The mx components were the multi-tool of the world. When you buy a kitchen appliance that
does -everything- you often find that it doesn't do -anything- with expertise. We spent millions
of dollars doing nothing but changing the SDK so we could begin to extend it. Components being
created inside of 500 line methods which access private variables so you can never change
the implementations via subclass. Hardcoded dependencies, hell, even the methodology by which
createChildren checks for the existence of a child before creating a new one so that you have
this primitive sort of override mechanism. All code smells.

>You had to recompile the whole sdk to add minimal functionality?
We maintain nearly 15 copies of the sdk each modified in different ways to suit client needs.
Try to fix the i18n issues of the framework when internally every object is bound to a hard
date instance or uses a set of string utilities which don't work 100% with 3/5ths of the world's
languages and you will quickly find that, to change one of those pieces (due to coupling and
hard dependencies) you have to override an entire branch of the framework class by class,
not just a node.

View raw message