>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.
