Thanks. That's good to know about Box. I believe Container is intended to be an abstract class, and while I was able to use it as the root of an MXML document, it didn't seem to do anything sensible (i.e. I couldn't see the children).
I guess if I was assured that Canvas is not horribly heavyweight (in speed and memory footprint) relative to Box, that would be my preference, since I can then avoid adding interim children in many cases. And a VBox nested in/on a Canvas seems more intuitive than a Canvas nested in a Box. On Wed, Jun 18, 2008 at 4:06 PM, Enjoy Jake <[EMAIL PROTECTED]> wrote: > Actually, a box with only one child is optimized to layout extremely > efficiently, so this is not a bad solution. Another possibility would be to > use the Container class. > > > ----- Original Message ---- > From: Richard Rodseth <[EMAIL PROTECTED]> > To: "flexcoders@yahoogroups.com" <flexcoders@yahoogroups.com> > Sent: Wednesday, June 18, 2008 4:00:48 PM > Subject: [flexcoders] Application components - Canvas vs Box > > I tend to have quite a few MXML application components in my > applications. Some are for re-use purposes, some are templates, some are for > wiring together MVC triads, others are just for organization. I haven't > noticed any performance issues due to the "extra" containers, some of which > may have a single child providing the actual desired layout. I tend not to > subclass components in ActionScript (though I obviously have plenty of other > ActionScript classes, and a couple of custom components) > > I've also tended to use a lot of VBoxes and HBoxes in my layouts, though > I'm using Canvases more and more. > > I've tended to make each MXML component a VBox, sometimes changing them > after the fact. But I'd rather just have an "organizational" root component > that can have a script block and do whatever non-layout binding stuff I > want, with a single child responsible for layout. i.e. less editing of the > first few lines in the file. Something like mx:Module without the layout > rules, I guess. The reader would skim over the small-as-possible script > block, and see a first tag indicating the type of layout. > > I see a couple of possibilities: > - Make each app component a Canvas, meaning I can dive in and position > children absolutely and with constraints, but it also has the nice default > of sizing to contain children, just like Box. Will often be adding a single > VBox or HBox child. This is the way I'm leaning, but I'm not sure how > heavyweight Canvas is compared to Box. > - Box (editing direction as needed, or adding canvases or nested boxes) > - Custom. Is it possible to write a custom component that can be the root > of an MXML file? It would be the simplest possible container, like a > Box-of-one. > > I'm interested to hear the practices of others. > > > > >
