layout

[Tyler Wright]

As Jacob alluded to there are other features that may or may not be considered part of layout. These are in addition to the built-in sizing and positioning capabilities of the DisplayObject such as x & y, scale, rotation, and 3D. They are features that can be used with DisplayObject (or Component) in absence of a parent's Layout as defined in a previous email. Below are a few of these added features:

registrationX, registrationY: the base point around which a DisplayObject is scaled and rotated

skewX, skewY: properties that allow a single DisplayObject axis to be skewed (rotation is an equal skew of both properties)

left, top, right, bottom: similar to the browser style equivalents, these numbers anchor the DisplayObject relative to it's parent's edge

dock-left, dock-top, dock-right, dock-bottom, dock-fill: DisplayObject fills an entire edge of the parent, where subsequent docked siblings fill the entire edge of the space remaining

tile-left, tile-top, tile-right, tile-bottom: similar to docking, does not fill an entire edge but aligns to an edge without changing size (stretching), where subsequent tiled siblings tile up next to the previous sibling

These features allow complex UI layouts without complex VBox/HBox structures. And because they are features of the object they affect they can enhance any DisplayObject, regardless of its parentage. Also it can all be encapsulated in a regular non-display that targets the DisplayObject for portability and composition.

I think I can dig up some old demos if this sounds like something we want to explore later. For now it's something to keep in mind as we discuss layout, validation and base component features.

Tyler

[Ben Stucki]

I'd really like to just table layout discussions for a bit. We'll get back to them soon, but I think the button component, for example, should be able to exist without a layout of any kind. Will the default one we make have a layout? maybe. - but you should be able to create a component without any layout - just everyday x & y. After working with OpenFlux on a few consulting projects, I really felt like putting it in the base component/view was overkill, and that it shouldn't be required to make components using our model.

[Tyler Wright]

On Thu, Sep 17, 2009 at 12:22 PM, Ben Stucki <bens...@gmail.com> wrote:

I'd really like to just table layout discussions for a bit. We'll get back to them soon, but I think the button component, for example, should be able to exist without a layout of any kind. Will the default one we make have a layout? maybe. - but you should be able to create a component without any layout - just everyday x & y. After working with OpenFlux on a few consulting projects, I really felt like putting it in the base component/view was overkill, and that it shouldn't be required to make components using our model.

agreed. While making definitions I wanted to distinguish between the concept of additional "positioning" properties and Layout, but both can be added or removed at any time and are not central to our component architecture.

[Jacob Wright]

On Thu, Sep 17, 2009 at 12:22 PM, Ben Stucki <bens...@gmail.com> wrote:

I'd really like to just table layout discussions for a bit. We'll get back to them soon, but I think the button component, for example, should be able to exist without a layout of any kind. Will the default one we make have a layout? maybe. - but you should be able to create a component without any layout - just everyday x & y. After working with OpenFlux on a few consulting projects, I really felt like putting it in the base component/view was overkill, and that it shouldn't be required to make components using our model.

I agree too. If we have a layout getter/setter on the base component class, it should be allowed to be empty or null. It should only be a point to set a layout on and not one that requires it or creates a default layout.