> > As part of my research, for now I think "Building large-scale > Flex applications is simple" is a false-proof statement. If you > don't believe that, please have a look to all those Flex application > which have to deal with more then 150 MXML files and all their > worries and issues they ran into during the last couple of years:
I may be wrong, but 150 mxml files is not that huge :) depending if the size of each mxml you have, personnaly I make them as much minimal as possible. This is much about optimizing updateDisplayList, validation and all these stuffs But you are right about Flex performance. IMO, designing a more modular component that allow to do less validation in a sense that it should be more smart, is a good direction. I propose to list all bad design we know about the Flex 3 and 4 frameworks and propose technical/designs solutions ; should the JIRA do the stuff? On Wed, Jan 11, 2012 at 10:59 AM, Sebastian Mohr <masul...@gmail.com> wrote: > I would like define a goal for future versions of Flex: > > Goal: "Strengthening large-scale Flex applications" > > > http://code.google.com/p/masuland/wiki/WhatsWrongWithFlex#3.1._Strengthening_large-scale_Flex_applications > > As part of my research, for now I think "Building large-scale > Flex applications is simple" is a false-proof statement. If you > don't believe that, please have a look to all those Flex application > which have to deal with more then 150 MXML files and all their > worries and issues they ran into during the last couple of years: > > * Heavy code rewrites and refactoring > * Migration from Flex 3 to Flex 4 issues > * Upgrading or switching the Microarchitecture (Cairngorm, Mate, PureMVC, > Robotlegs, Parsley, Spring AS, Swiz) > * etc ... > > A more complete list of things that effect large- > scale Flex applications can be found here: > > > http://code.google.com/p/masuland/wiki/WhatsWrongWithFlex#2.2._What's_negative > ? > > Please read and disagree, > > > -- Sebastian > > >
