Thanks for sharing your efforts.

Peace

Should be:

override protected function partRemoved(partName:String, instance:Object):void{
if(instance == headerGroup){
headerGroup.mxmlContent = null;
} else if (instance == sidebarGroup) {
sidebarGroup.mxmlContent = null;
} else if (instance == footerGroup) {
footerGroup.mxmlContent = null;
}

super.partRemoved(partName, instance);
}

I wonder if anyone has looked at creating custom layouts for non-repeating content? Every single example I’ve seen has assumed repetion. It seems to me, we should be able to create a view-specific layout that can position items individually – so that the decision about where to position them is contained in the layout, not in the MXML markup. That way we could maintain semantic declartions right down to the contents of the containers.

At the core, the goal is to connect a chunk of formatting info with a content bucket. In HTML, CSS is one way. In Flex, a custom layout is one way. But what is best?

I’d say if you need a one-off view, then as you say, just code & skin that view and pass it through to the content bucket. If you need something repeatable, I’d recommend the custom layout route.

I really like what you’ve done here. The separation is really nice, however I think there is a fundamental problem caused by the way Flex is put together. In your examples, layout is governed in your content-slots by the groups layout props inside the skins. This is great, because layout declarations are kept inside the skin, and you can declare the content inside your main mxml file without needing to polute the semantic tags with any layout code. However, what if the layout is a basic layout and you need a button at x=”30″ / y=”45″ and an image with width=”100″ height=”200″? You are stuck declaring this layout information inside the main mxml file.

If you look at the way HTML handles this, complete separation is achieved through CSS. We can almost get there, but x/y and width/height are not settable through CSS, so we are stuck.

We can work around this limitation by using another layer – a view that fits into the content slot and declares its content as skin parts, but this is a far from ideal solution.

Would be good to hear your thoughts.

@Jabby: Great point about using IDeferredInstance, and a really great point about using “templated” components for the Flex 3 holdouts.