flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glenn Williams" <i...@tinylion.co.uk>
Subject RE: Missing Spark Components List
Date Fri, 02 Mar 2012 11:38:44 GMT
Im really torn with this one (V\HGroup et al)

1. I totally agree with you. Container + layout,
is all that's needed
2. I always end up using the convenience of VGroup
and HGroup when laying out (with mxml anyway. just
tidier on the page to read.)

I absolutely agree with what you're saying, but
end up using them anyway when it comes down to it.

For me the idea of Spark is that you can have
VGroup like classes but still know they are built
from very specific building blocks and not big
masses of code.

Are you saying just don't have these kind of
classes in the SDK but just let people make them
themselves or that you shouldn't use classes like
that and go the more long hand route of typing in
the container then the layout? 

As long as I know that VGroup is only a short hand
of what I would have written long hand then I
don't see the problem , only the convenience.

I can see how adding those kind of things just
expands the size of the framework and if aren't a
core then aren't really needed. Maybe removing
these purely convenience classes out into a module
that could be used\not used depending on what the
dev wants? Having a sparkCore\sparkExt kind of

I really shouldn't start typing before Ive decided
what my actual opinion is lol

I think on this issue im definitely +1 and -1 I
don't even agree with myself anymore.

One question, apart from sdk size, is there any
additional overhead when using VGroup for example
rather than Group and adding a layout?


-----Original Message-----
From: Tink [mailto:flex@tink.ws ] 
Sent: 02 March 2012 09:42
To: flex-dev@incubator.apache.org
Subject: Re: Missing Spark Components List

I'm with Jonathan on this

I pushed for Adobe to remove HGroup and VGroup
before the release of spark as I saw these as
absolutely pointless.

In spark we should use a container or data control
and then add the required layout. There is no need
to bake in layouts and expose their properties to
the component, just pointless. Too late to removed
HGroup and VGroup now, but please lets not add any
more classes like this. It dums down what you can
achieve with spark.


View raw message