Wow, the thread on this simple topic has gotten quite large. One of the main complaints against how Spark was originally written was that it was too inconvenient. That is the main reason the ship date for Flex 4 got delayed. We need to find a good balance point between ease-of-use and strict compositability.
I'm against having a SkinnableSpacer class, but I'm all for having a Spacer class. It would just be a subclass of Rect with no extra properties or anything. There are two main reasons why I think we should have it: 1) people coming from MX expect it, and 2) semantically it's different from a Rect. While it's true that someone can easily write their own Spacer class to achieve this, but lots of people don't use Rect, which is more light-weight. Plus, I think this case is really common and something we should support. I think it should be a subclass of Rect for performance reasons...if people need something else, they will figure it out. If people want a Skinnable or fancier spacer, they can create a simple custom class for their own purposes. -Ryan On Thu, Mar 1, 2012 at 8:01 PM, Om <bigosma...@gmail.com> wrote: > 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 > > > > > > > > >
