flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <omarg.develo...@gmail.com>
Subject Re: s:Spacer (was Re: Missing Spark components)
Date Thu, 01 Mar 2012 18:55:38 GMT
On Thu, Mar 1, 2012 at 10:37 AM, Michael A. Labriola <
labriola@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
Apache Flex PPMC Member

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message