On Thu, Mar 1, 2012 at 10:37 AM, Michael A. Labriola < labri...@digitalprimates.net> wrote:
> >I didn't put 100%, I put just 100, 100 pixels. :P > > I know and I knew you were going to call me on that but my over the top > approach didn't work as well with 100 pixels. > > >But I get what you're saying, however, I still think that easing the > migration path is a worthy endeavor. I'm not saying we need a class for > every possible composition, that's ridiculous. But I think we can raise the > barrier to entry >for some MX users. You've stated several times many > companies are still on MX, I've talked to many companies as well that have > tried to do the migration from MX to Spark. The biggest pain point I > commonly heard was the >unclear path of migration for some of their > components. Its not like based on the list I'm proposing for hundreds of > new components, its but a small handful of convenience classes, some of > which already exist such as s:HGroup >and s:VGroup. > > I know. For consistency though, I actually argued against VGroup and > HGroup too :) We see how that went. > > Mike > Fair enough, I was thinking about how inconsistent VGroup and HGroup were to a tighter lighter framework. Heh, it is what it is at this point. What if we put these convenience classes like s:TileList and s:LinkButton in another package, like spark.components.convenience, or some other name. We can then compile that into its own SWC and it can be an optional part of the framework you can choose, or choose not to, use. Either way, I think they have value. If they're rejected as a donation to the SDK I'll just throw them on GitHub. -- Omar Gonzalez s9tpep...@apache.org Apache Flex PPMC Member
