Flex 4.0 drag-and-drop with skins

UPDATE

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.

ORIGINAL POST

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 s:Skin classes.

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 dragEnter and dragDrop events (in addition to all other DragEvents.

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 s:Skin class.

Three links that helped me with this endeavor:
saturnboy drag-and-drop
evtimmy drag-and-drop skinning
From above:
Adobe drag and drop examples

Read Full Post »

flex 4 compile error “‘mxmlContent’ must be contiguous”

Converting over from 3.5 to 4.0 has been a blast. Lots of new features have been introduced. However I started to see this error every now and again:

Error: Child elements of 'Group' serving as the default property value for 'mxmlContent' must be contiguous.

I would be able to get rid of it undoing whatever I had recently changed, but I pushed it to the back of my mind until now. I can replicate this error by creating a group that contains a layout tag after any visible children.

Over zealous copy/pasting a rectangle with a stroke into a group tag, bumping the layout tag lower caused this error for me.

Flex, trying to add visible elements and not knowing how to layout this component complains that child elements aren’t contiguous. Needless to say, the error message could be worded differently.

This code generates the error. Notice the comment to fix the error; move the layout tag to the first element after the declaration.

<?xml version="1.0" encoding="utf-8"?>
<s:Application name="Test" xmlns:s="library://ns.adobe.com/flex/spark">
<s:Group>
	<!-- border/background graphics -->
	<s:Rect width="100%" height="100%">
		<s:stroke>
			<s:SolidColorStroke color="0x000000" weight="2"/>
		</s:stroke>
	</s:Rect>
	
	<!-- move the layout information to the first declared elment
                 after <s:Group> to solve the error. -->
	<s:layout>
		<s:HorizontalLayout/>
	</s:layout>
	
	<!-- content of container -->
	<s:Label text="test" />
	<s:Graphic >
		<s:Ellipse width="12" height="12"
				   x="0" y="0">
			<s:fill>
				<s:SolidColor color="0xFF0000" />
			</s:fill>
		</s:Ellipse>
	</s:Graphic>
</s:Group>
</s:Application>

Looking at the documentation (see below) we see that ‘mxmlContent’ refers to the visible children of that mxml tag. The description clued me that the error message referred to layout and children of the container.

[Write Only] The visual content children for this Group. This method is used internally by Flex and is not intended for direct use by developers.
The content items should only be IVisualElement objects. An mxmlContent Array should not be shared between multiple Group containers because visual elements can only live in one container at a time.

If the content is an Array, do not modify the Array directly. Use the methods defined by the Group class instead.

Language Version:
3.0
Player Version:
Flash 10, AIR 1.5
Product Version:
Flex 4

Read Full Post »

3.5 to 4.0 Flex SDK upgrade

We have an application that requires upgrading from 3.5 to flex 4.0 SDK.

Needless to say our app did not compile on the first try with no code changes, that would be too easy. Digging around I found this great article on why the move to 4.0 enhances your ability to code following a MVC methodology:
Spark Styling.

This concept will hopefully allow us to change many of our sub-components into one .mxml file with different states. Looking forward to getting our code base converted.

UPDATED:

I wanted to put to words a general way for going about the upgrade process that I haven’t seen out on the web. Note I use ant tasks for building this flex project (contains java) but similar functions could be accomplished with IDE admin window.

1) Point ant to new Flex SDK 4.0, hold-breath and compile. Of course this doesn’t work, there were some api changes that required updating of the original code.

2) Try compile again. Now it’s complaining about fonts and halo themes and all other sorts of issues. Explicitly name the font renderer in the ant task, compile in compatibility mode 3.0, update namespaces and try again.

3) Now when I tried to add a new spark components it complains about being compiled in compatibility mode. Which makes it useless as a transition tool, and only served the purpose of convincing myself that I could in fact convert this application.

4) Luckily when I removed the compatibility option all the compiler complained about where attributes that had been abstracted to the spark skin layer. Since the whole point of converting was to take advantage of this new layout I just made note of all the attributes I removed and categorized them into skin classes I would need.

And now I am currently in the processes of learning skins … although my golf game is pretty rusty.

Read Full Post »