The opposite of a skinPart

SkinParts are a great way to add event handlers and logic to an object that is instantiated in the skin, away from any business code. Often, though, I find myself wanting to do the opposite, and define parts that will be us开发者_开发问答ed in reusable, skinnable containers in the parent mxml files which will be inserted into the skinned containers.

What's the best practice for when you want to be able to define a control and a skin which can be reused with different controls inserted from outside the skin?

Edit: A better way to put this might be that I want to use something that works a little bit like a SkinnableContainer, but that isn't limited to one area where content can be placed.

---

I find your question a bit inexact, so I'm not completely sure I understand what you're looking for. But, I'm going to give answering this a shot.

SkinParts are a great way to add event handlers and logic to an object that is instantiated in the skin away from any business code.

I wouldn't say that SkinParts allow us to add event handlers or other logic to an object. Although from a development perspective, it appears that the Skin (extending Skin) and the Business Class (Extending SkinnableComponent), and two separate entities; at runtime they really seem to be treated as a single entity.

I haven't delved into the the actual framework code, but from what I gather, the Skin is the actual display object added to the stage, and your Business class is somehow merged into it. If you look at ActionScript skins being introduced in Flex Hero, you'll find they require a hostComponent property of which the type should be the business class. I assume this is what the Flex Compiler already does behind the scenes in Flex 4.0/4.1 using the HostComponent metadata.

Often, though, I find myself wanting to do the opposite

The opposite of what? You want to add event handlers to a component inside the skin There is no reason you can't do that, although that is not the direction Adobe pushes us towards when creating components in the Spark Architecture.

If you want to create your own "discrete packages" of data and functionality that can be easily reused, you can do that to. Any Spark component, Halo component, or non-Flex ActionScript Class can be used to easily these reusable objects which can then be reused in another Spark or Halo component.

I'm not completely sure if this answers the question. But, if you care to elaborate we can try to help best we can.