Trying to illustrate to my fellow developers at work which view classes represent what part of the interface we’ve been given by the design team. Last time, I took screen caps, wrote just the classname itself at the top, and put them all in 1 big webpage. This was easy to check into Subversion, and you could use Control + F in Firefox or IE to quickly find a classname on the page to “see” what you were building. I’ve seen others actually screen cap the design, and bring that in as a guide layer on the component itself. This worked great in Flash MX, but with MX 2004 and classes maker a clearn seperation of code and GUI, it doesn’t work as well.
We make decent use of Flash’ Project Panel here. It is merely for organization; you can clearly (sort of, it’s kind of cramped) see the entire project. All the AS files in their packages, the currently 3 FLA’s, the JSFL’s, and the includes. Since most of us Flash guyz use Flash to code in, it makes it really easy to open up a class file; you just double click it. It’s a pain to keep in sync with the folders, but I’ve sort of elected myself to ensure it’s in sync because I believe in it’s ability to keep us all on the same page.
I combined both the Project panel and my viewing of the classes as interface screen captures. I load the Project’s FLP file into a Tree component, and since it inherits from List, I use a labelField function to return attributes.name instead since Tree’s expecting a label attribute. For folders, this works great; if the node has a path attribute it’s probably an AS file, so I just chop off the filepath, and show the file name.
import mx.controls.Tree; createClassObject(Tree, "project_tree", 0); project_tree.labelFunction = onNodeLabel; function onNodeLabel(item) { if(item.attributes.path == null) { return item.attributes.name; } else { var a = item.attributes.path.split("/"); var str = a[a.length - 1]; return str; } }
When you click on one of those class files, if it’s a View or Controller, it loads its equivalent JPG, located in the docs folder 1 level up, same classpath structure. This way, using the same project file, you can navigate to the fully qualified package path, and see the image the class represents.
Finally, sharing FLA files amongst many developers sux. SharedLibrarise are a management nightmare, even with JSFL skillz, linking to symbols in other FLA’s using a main FLA makes your compile tmie skyrocket (and again, is a management nightmare since it’s now only a compile time deal). For now, since Subversion doesn’t support check out, we just constantly communicate. Flex, aside from it’s weird embedding of assets, would abate this problem.
How are others handling it?
Loading the flp in a treeview… clever! Sometimes I wonder why in the world they let treeview work with XML as a source instead of just plain old dataProvider, then this reminds me it has some purpose.
I use CVS on all my AS files but have had terrible issues with working with flas as well. Usually I commit them every day or say just to have a backup, but I wouldn’t dare doing collaborative work on an fla. I guess that’s why we need Flex, don’t we. If only it were affordable…