incubator-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 17:58:24 GMT
On Thu, Mar 1, 2012 at 9:48 AM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:

> > This is exactly why I feel we should have these. People first
> > instinct, at least mine was, was to look for an equivalent. Subclassing
> <s:Rect/> with convenience setters would go a long way toward reducing
> frustrations people have had with migrating. Not everyone is immediately
> aware of >all the skinning possibilities and new paradigms such as the
> layout object so anything we can do to smooth out the migration is a plus.
> Plus it illustrates proper use of some of the Spark concepts. Don't see how
> its a bad thing. If >people really want to keep writing out a few lines for
> a Rect as opposed to just writing <s:Spacer width="100" /> then that's
> their choice but I think we should have the class available so I'm going to
> code one up today.
>
> Just my 2 cents. This all seems dangerous. Have a composed implementation
> of each individual set of classes just gets us back to mx.
>
> Why set the width to 100% on a space, why not have <s:FullWidthSpacer/> or
> <s:FullHeightSpacer/> then you don't need to set the properties at all?
> Incidentally, I support that idea (honestly) if someone want to compose
> objects in their own framework or project for their own use, but does the
> SDK really need to have every combination of composition that's possible?
> To me that is opposite  of a small, tight SDK.
>
> Mike
>

I didn't put 100%, I put just 100, 100 pixels. :P

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.

--
Omar Gonzalez
s9tpepper@apache.org
Apache Flex PPMC Member

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