Layout

[Jacob Wright]

Actually, the topic of layout on behavior had me think about layout in general. We don't need it as a behavior by any means. I started a new thread to discuss layout in particular.

There are two parts to layout. There is the layout algorithm which lays the children of a component out. This would include vertical and horizontal layouts, coverflows, etc. Then there is the layout properties on the component such as minWidth, maxWidth, measuredWidth, explicitWidth, etc. You'll find that many of these properties are needed to have layout be as smart as Flex's without having to define every width in the system. But for a simple project you probably don't want or need all this.

Should there be two layout objects? One that has the algorithm for children, one that has the data for an individual component? They could work behind the scenes simply updating a component's width and height. Or should we build all the properties into the base component class like Flex does?

One way to do it:

list1.layout = new SimpleLayout(); // doesn't really do anything

list2.layout = MeasuredLayout(); // lays out smarter with measuredWidth, minWidth, etc.

list2.layoutAlgorithm = new VerticalLayout();

Am I overcomplicating this? Or is this the way to go to allow minimal and robust layouts?

Jacob

[Ben Stucki]

I don't think we should dig too deep into the layout until we get more defined on the the core component triad (layout is not a dependancy for this). - but as a general statement I don't think these are separate at all. If one does layout based on constraints and measurement, and the other doesn't - so what? They're both layouts. I think OpenFlux has a pretty good system for dealing with this, so I would probably look at it as a basis. It's still a separate class that can be use on it's own without the rest of the framework.