Regarding “linking library assets to already existing Classes”.

How do u compose deep-nested display objects? Let’s say designer draws a hand-made quiz set (some code needed for this object), where there are some question-answers objects, each is a complex component (with some code to be in there aswell). If u would develop this in Flash IDE u would just assign base classes for all those quiz-sets and for each answer objects. But when developing in a normal code IDE (FDT, FB, IntelliJ, FD, etc) and compiling with mxmlc — u can’t really* (NB! Actually u can, explained below) use this workflow. To sum up them:

1. Export to SWC/SWF, don’t use any base classes. Extend assets to add some code.
pros:
+ designer is 100% independent from code stuff.
+ [SWC] no need to load any external SWFs — classes are ready-to-use at startup.
+ [SWF] no need to recompile main app to update graphics (since they’re being loaded in runtime)
cons:
- your custom classes (MyAssetWithCode extends GraphicalAsset) can’t be any but Sprite/MovieClip (I mean u can’t make it be some UIComponent)
- no nested layouts
- multiple assets can’t inherit same code base (well that’s because code extends graphics)
- [SWC] recompile to update graphics
- [SWF] need a bit of extra functionality to load SWFs

2. Export to SWC/SWF, don’t use any base classes. Use composition to add graphics to your coded objects.
pros:
+ designer is 100% independent from code stuff.
+ same about loading as in CASE.1
cons:
- no nested layouts
- same about loading as in CASE.1

3. Write [Embed(source="/assets.swf#MySymbol")] just above class definition.
pros:
+ nested layouts are possible
cons:
- compiler doesn’t work correctly when using incremental compile, e.g. code-asset are not successfully paired sometimes. So u have to reset compiler/forget about incremental compiling, which is awful.
- if u want N assets to have same base class, u have to manually create N classes and extend them from MyBaseClass
- recompile to update graphics

I personally used CASE.3 during some small period in my work, but finally found it very unfriendly.
I can’t imagine how to use 1&2 regarding layouts. I mean if u have some handmade custom layout from designer (it depends on kind of project, but I have it all the time), then there should be some markers where to put objects. Then you have to create all of them in runtime, transform, apply filters if needed (NB! regarding “composition”. I think it’s better not to put the asset itself, but directly add children. For performance we have to keep as low depth of nesting as possible) and so on… In addition designer won’t be happy to put markers instead of actual objects since it’s not quite visible what will you get… Any hints regarding this workflow maybe, anyone? Because it looks like the best (the most flexible) approach, but this layout makes me feel sad.

* So for now I have a 4th CASE. This one fully mimics workflow you had in Flash IDE. I use it
4. Export to SWC, set class to “assets.MySymbolAsset” and base class to “projectPackage.MySymbol”. The FLA has to see classpath where you have projectPackage.MySymbol class, so in my case fla file is located in /libs/fla folder and has class path “.;../../src”. The main trick happens when you publish to SWC. I have a special JSFL script that creates a temp folder “code” in the same folder where FLA is, updates FLA settings by adding this folder into classpath (as primary, first one), then creates dummy empty classes in this temp folder for each symbol that has base class, and finally compiles SWC. So the resulting SWC has NO actual code inside, but an empty classes with the same name as the real ones. This JSFL script also allows designer to compile it.
Next about compiling the application itself. Since graphical assets have the same classes names as the real ones with actual code, the actual code kinda injected into assets. This eliminates all the cons from the other mentioned cases, e.g. you have deep nested structures with an actual code for each components.
But there’s basically two cons:
- you can’t distribute assets into several SWC this way if some reference classes present in both. E.g. if Asset1 from assets1.swc extends MyComponent and Asset2 from assets2.swc extends MyComponent — u’re screwed.
- base classes from fla should have the same name as the real ones, so if your fancy IDE has a nice refactoring support — u’re lucky. But still have to change everything in FLA somehow (manually/JSFL).

More about this workflow. To create a new object it’s handy to write this way:
var foo:MyComponent = new MyComponentAsset(); // remember that MyComponentAsset extends MyComponent. MyComponentAsset is dynamic (due to FlashIDE), but MyComponent is not.

So again, any tips on comfortable composing layouts with workflows 1 and 2? Because they seem like more “right”.

Fix @ http://dl.dropbox.com/u/2400762/Adobe/Commands/Export%20Library%20References.jsfl