mx.controls.Spacer is nothing but a UIComponent. It adds nothing and it modifies nothing. The only difference is the usage in a given context. To keep it consistent, we should just copy it over to spark.components.Spacer and call it a day. This addresses the problem of halo vs. spark component parity and reduces developer confusion. Also, there might be implementations where Spacers can have click or mouse over handlers. If we change the internal implementation to s:Rect, we might be breaking those applications preventing a clean transition from halo to spark architecture.
If Spacer needs to be skinned i.e. SkinnableSpacer, we can create a separate component in the spark.components package. That said, I dont think I would want to use a s:SkinnableSpacer when I can just use a s:Rect. Thanks, Om On Thu, Mar 1, 2012 at 11:31 AM, Arnoud Bos <arn...@artim-interactive.nl>wrote: > > > > > 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. > > > > Personally i like many components. If this bloats the SDK then i'm all for > a split like > Flex and "Flex extended" or whatever. Of course people can make components > like > SearchBox, AutoCompleteInputField, etc with the current available > components, but > it's just more work. If there's a repo where those extensions are > available i would be very happy. > > For me it simply would speed up development. Choose the component that > matches your needs closest and adapt in a minimal way. I use VGroup and > HGroup > for example a lot. Shorter code, less typing and therefore easier to read. > But i can understand > that here we want to focus on a rock solid core with a basic set of > components. > But a central place for adding those convenience extensions would be great! > > Met vriendelijke groet, > > Arnoud Bos > Artim interactive > T +31 6 246 40 216 > E arn...@artim-interactive.nl > > > >
