I put this at the top because I wanted to change the content of the below post. Having worked on this code for a few days now, I became aware of several short-falls in my assumptions.
1) You cannot extend skins. Which makes sense, a host component can have many skins which have many states. Extending a skin would add confusion as to where the states are defined for that “look and feel”.
2) Enabling drag and drop (while a UI interface function) on custom components through their skins is asking to violate the DRY principle. Even though the skin is now the top most layer of the <code>DragEvent</code> having different skins breaks this model.
Unfortunately the drag and drop examples from adobe for flex 4 still show mx components, but the differences page seems to lean towards putting drag and drop functionality in the spark component, not the skin class for the spark component.
Another upgrade bit of confusion that has since been squared away.
In the original application,
mx:Panels were dragged around on a
mx:Canvas; something similar to the Adobe Documentation examples
Both of these files were getting quite large as they handled look and feel, interaction of the components, and all data. Now with flex 4.0, one priority was to convert these two custom components to
s:SkinnableContainer with respective
This has cut our file sizes 20-50 percent as we try to follow a more MVC architecture. However our drag-and-drop functionality ceased to work for these custom components.
Long story short, drag events were now showing the
s:Skin class as the
dragInitiator for a
DragEvent instead of the (in my mind) expected host component of the skin.
This make sense from the point that the added skin is now the ‘top-most’ layer of the component, but the question of where to put the custom drag management code naturally presented itself.
Does it belong in the base “data” class (Component), or does it belong in the “skin” class (ComponentSkin). Adding to the confusion is that both classes accept
dragDrop events (in addition to all other
Knowing that the outmost layer of the component is the skin, and attempting to adhere to the MVC architecture, the decision is made to include all drag (ie visual) effects in the