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 thing. 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? Glenn tinylion -----Original Message----- From: Tink [mailto:f...@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. Tink
