AS3 Class to Asset Linkage – something different?

 Dec, 22 - 2008   2 comments   How ToThings that are broken

I decided I’d try an FLA-less project using embedded library assets from swfs, but that proved contrary to my workflow. If I’m going to use the IDE for layout, then I’ve got a good handful of layers. Not just a graphic or three. I want several things to align, you know visually, so I used a visual layout tool to configure my layout. Smart, huh? But you can’t pull in an entire timeline worth of assets and then provide the class and still expect to get the whole thing wired up. Flex compiler’s gotta be all one child asset at a time within the class.

Despite reading more than once that you could somehow:

[Embed (src="library.swf", symbol="layout"]
public class layoutClass extends Sprite
// rest of class here

I never got it to work. I only got the directive to work for class property members, not the class definition itself.

You could use composition to pull an entire layout’s worth of assets in. But then you’ve got this magic asset container property that’s different from the local “this” context. No, I wanted all the assets linked to the class in one place, like I was used to with the IDE in the first place.

I decided it was worth it to reparent all the assets out of a temporary holder, and reconstruct the layer stack in the new parent.

I knew the code for this wasn’t hard or long, but it isn’t exactly obvious:

//Layout is a class that can be populated via
//embed directive or by having a 'skin' swc in your classpath. 

var layout:Sprite = new Layout()

var len = layout.numChildren
for (var i=0; i<len ; i++) {
  //move the child into this
  var c = addChild (layout.getChildAt(0))
  //link the property name of the class to the asset
  this[] = c

Merry WhateverDecemberweenNewYear.

Related articles

 Comments 2 comments

  • Pavel fljot says:

    Are you still doing it this way??

  • jon jon williams says:

    Not as much. I’ve recently become more comfortable leaving the assets inside a “skin” container (layout in the above example). Effectively, I suppose that means I’m embracing the composition pattern.
    It depends on what the goals of your architecture are though. Does it make sense to define an interface if you’ll have more than one skin implementation? “Is-A vs Has-A” should become a mantra that you don’t have a pat answer for. I’m a big fan of having a LOT of different approaches in my toolbox. I’m sure I’ll reach for this one again eventually.


  • Leave a Reply

    Your email address will not be published. Fields with * are mandatory.