One of the benefits Degrafa offers as part of the framework is the ability to repurpose code to no end. This may be obvious for things like geometry, but if you find yourself writing redundant code for fills and strokes, this tip should help.

Rather than specifying the same common fills and strokes in every MXML file where you’re doing your drawing, you can separate fills and strokes in to their own MXML files. Then, whenever you need to access a fill or stroke, you can add that component to your MXML file and easily access them when appropriate. By doing this, you also have the advantage of code hinting, which makes for quick and easy coding.

As an example, I could make a Fills.mxml file where I specify a fill, like this:

<?xml version=“1.0“ encoding=“utf-8“?>

<GeometryComposition
	xmlns:mx=“http://www.adobe.com/2006/mxml“
	xmlns=“http://www.degrafa.com/2007“
	>

	
	<SolidFill
		id=“grey“
		color=“#666“
		/>

</GeometryComposition>

Then, I can reference that MXML file wherever I’m drawing with Degrafa. For example, the following Circle.mxml code would reference the Fills.mxml:

<?xml version=“1.0“ encoding=“utf-8“?>

<mx:Application
	xmlns:mx=“http://www.adobe.com/2006/mxml“
	layout=“absolute“
	xmlns=“http://www.degrafa.com/2007“
	xmlns:local=“*“>

	<local:Fills
		id=“fills“
		/>

	<GeometryComposition
		graphicsTarget=“{[ surface ]}“
		>
		<Circle
			radius=“100“
			fill=“{fills.grey}“
			/>
	</GeometryComposition>

	<Surface
		id=“surface“
		verticalCenter=“0“
		horizontalCenter=“0“
		/>

</mx:Application>

Those two code samples represent some of the basic methods for cutting down on the amount of code you need to write. I could reference that Fills.mxml in any other component and use the fills defined in that file. You could do the same for strokes as well or make separate MXML files for each type of stroke or fill. It’s up to you. I put together a more evolved example than what was shown above and you can view it here:

View External Fills and Strokes Example
(View Source enabled. Also available on Degrafa Samples page)

Taking This Further

You can expand on this example by making separate Fills and Strokes files for different parts of an application, share those files with other Degrafa users, adjust the structure for what makes most sense for you, etc. One thing that would be interesting is to make a separate Colors class that you can reference from the Fills and Strokes files. Then, when you change the color values in the Colors class the whole scheme of the app could change. Hook that Color class up to a color API like Kuler or COLOURlovers and you could get some really unique opportunities for custom UIs, data visualization, compositions, etc.

We’ve been thinking about a way to grab a color palette using a color API, present a user with a bunch of variations of Fills and Strokes based on that selected palette, allow for selection of which Fills and Strokes the user wants, then write out MXML files with those selections in it. The user could then drop those MXML files into their Flex project and they’re ready to go. It could work the other way too where a user could read an MXML file and be presented with Fill and Stroke swatches of which they can edit and write out a new MXML file.

The more we keep plugging away on Degrafa it seems there are more and more opportunities for creating some really unique tools. Imagine a Fills and Strokes palette that uses the Fills and Strokes MXML files as the model. Who knows what other kinds of things people will come up with as the framework progresses. Any suggestions?