views:

1204

answers:

3

Let's compile a list of tips.

(Understandably there will be some subjectivity involved, but some pointers would be useful to someone overwhelmed by tackling a large project within the Flash framework.)

+2  A: 

These are just scattered thoughts on organization for projects being worked on mostly with the Flash IDE.

First, I highly recommend using source control, like Subversion, CVS, or Git.

Organization of filesystem folder structure is subjective, but I generally have a "src" folder for all my source FLAs and AS class files, and a "deploy" or "bin" folder for compiled files. The src folder would contain class package files, with class packages organized in reverse domain style (e.g. - com.codehinting.projectname.context ). Modify the publish path of your FLA to publish to the deploy folder by tracing back up using the "../" path segment, for as many levels as needed to trace back from the nesting in the src folder.

Also, I typically place third-party libraries (that are pretty well "baked") in a separate location and then modify the global classpath in the Flash IDE to point to this location.

Two extremely handy plugins for the Flash IDE are Create Basic Layers and Library Generator, which quickly create your skeleton layer and library folder structure - saves time versus manually creating layers and folders.

Matt Braun
+1  A: 

I adopted the Project Naming guidelines from Blitz:

Blitz Project Naming Conventions & Organizational Guidelines

My DEV_Source is divided in database/flash/flex directories.

The Flex directory is standard to the Adobe conventions, but the flash has a custom setup.

bin -- Output of SWF, contains JS and index.html
classes -- AS3 code
doc -- AS Doc output of code
libs -- 3rd party libraries and components
src -- FLA files (set the Publish settings to compile in bin)
test -- AS Unit test cases of classes

Pascal Immerzeel
A: 

A complex project will have many dependencies. In my Flash projects, I put all my libraries in a version controlled location as they are. Third party libraries are usually a mishmash of assets, code, demos and docs.

I keep a small yaml file that keeps track of the location of each type of resource associated with each library on my system. When I add a new library, its location goes into this file first, then I run my Ruby script to move the files over to a single location. This way there is no jockeying around with third party library paths, and making sure include paths in my projects match in my fla files and Flex builder projects.

A single source to bind them all.

picardo