degrafa

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?

One of the driving forces behind Degrafa is the need to close the gap between Designers and Developers constructing applications in Flex. Typically when working on a project a designer will create the graphic assets in Flash, Illustrator, Fireworks or any other vector or bitmap authoring software and then hand it over to a developer to implement.

This is what I will do, except I do all the MXML implementation of skins or any other graphics necessary to get an application looking the way I want it to. Most of the time I work in Flash, then bring everything over to Flex. This works great.

However, there comes the redundancies of making changes to graphics when needed. So, I open Flash, make the changes, publish a SWF/SWC, then go back to Flex and make sure everything looks good. If not, repeat.

Wouldn’t it be great if you never needed to leave the Flex work environment to do this or if you could just repurpose similar buttons into different colored buttons instead of making a separate graphic or programmatic skin for those small variances? Well, with Degrafa you can, by utilizing the available Drawing APIs and more.

You might be thinking, the Drawing APIs? Don’t I have to know ActionScript and how to even use the Drawing APIs? Typically, yes. However, another part of bridging the gap between Designers and Developers is creating a legible and easy to use framework which uses MXML markup. Degrafa does this. So, you could create graphics assets very easily using Degrafa and they’re right there in MXML for a designer or a developer to manipulate as they see fit. Consider the following example:

The Clock

This clock was created with roughly 40 lines of MXML using methods mentioned in the last post and no ActionScript.

The Parts

There are several items that make up this clock. Fills, Strokes, layered Geometry Groups, Lines, a couple Filters and a Repeater. The first 4 items I mentioned in a former post and the Filters are just flash.filters.

The Repeater comes in handy for the hour tick marks on the face of the clock. Typically you might draw each line with it’s own X and Y positions, but with Degrafa’s Repeater you can specify one line, a rotation point, offset points, and a repeat count. With that you make what could have been 12 lines of MXML into about 3.

Add Additional Interactivity

Now that we have our clock we can have it do more than just tell time. The face of the clock could change colors to represent time of day or create an alarm clock where the face started turning redder as it got closer to the alarm time. We could change the shape of the hands or change the clock from circle to a square. Values of any attributes of the different shapes that make up the clock could be bound to any type of control or data set.

With static vector or bitmap assets it would be hard to do this. Not only that, but now a developer doesn’t need to get into Flash or Photoshop to change something as basic as a color. All they need is the new color values and they just plug them in.

A Visual Tool Set

With both designer and developer working on a common level with MXML some really great things can happen. However, there will be designers who don’t even want to look at code.

That’s understandable. Which is why we’re planning on creating a set of visual tools to accompany the framework. Then designer’s will be able to take advantage of the features of Degrafa without too much resistance. Sound good? We think so.