> > So if paying for the flex Ide is their only revenue point, to say that the > mx components were badly written is false. They hit exactly the crowd that > they needed to hit with them. You may be happy with the spark components, > but that's when flex died, after they were introduced. When the little guy > was pushed out. >
This. I love the spark architecture, but that's because I have used mx exhaustively (pushing its limits) and I know all the pain points. So, moving to the Spark architecture was a logical progression for me. But, this also means that new folks that start using Flex 4+ for the first time, dont have an easy entry point. Changing the look and feel of an app - which was extremely easy in mx is now a chore. I know and have worked with design firms that created new application styles using the 'Flex 3 Style Explorer' - which was an online flex application. Thats it. Thats how easy it was to work with mx components. I dont know if the answer is better tooling (Catalyst, Design view, etc.) or if it is a question of more exhaustive documentation, working examples, tutorials, etc. Or even a change to the way Spark approaches skinning and customizations. This kind of developer outreach (especially for newbies) should also be a goal for the Apache Flex project, IMHO. Thanks, Om On Fri, Mar 2, 2012 at 5:10 PM, Cortlandt Winters <c...@cortwinters.net>wrote: > Thank you, Micheal for a great response. > > I think what we have here are two radically different use cases. > > On the one hand flex needs to be a good enough framework that a team of > three can create something of real value on a 10-30 thousand dollar budget > in a few months. Without rock stars. > > On the other hand how can a team of 100 which was probably 10 times the > number of core flex developers, do world class stuff if the sweet spot is > for a team of 3-5? > > But frankly from Macromedia/Allaire and Adobe's standpoint, there are > probably a thousand times more users > in the first scenario than the second, maybe ten thousand more. > > So if paying for the flex Ide is their only revenue point, to say that the > mx components were badly written is false. They hit exactly the crowd that > they needed to hit with them. You may be happy with the spark components, > but that's when flex died, after they were introduced. When the little guy > was pushed out. > > I reiterate that there is not a single complete commercial spark component > skin on any marketplace after two years. Mx skins weren't in the 100's but > there were 30 or 40 attempts. > > Frankly, If you have a hundred developers, you had more than enough > resources to take the core as3 language and build your own framework that > covers this larger set of world class issues with a less feature rich end > point. > > I have no doubt that given this experience you are well suited to guide the > core framework internals in the future, but not if you can't recognize that > it's a niche case and that mx covered 95% of most user's needs. > > Most projects can't create components for the project. Most projects use > components to build the project. That's why they are called components. > They are reusable. Most projects are focused on the content and use the > components to display the content. > > > On Fri, Mar 2, 2012 at 9:36 AM, Michael A. Labriola < > labri...@digitalprimates.net> wrote: > > > >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. > > > > >
