Organizing a Flex Project for Team Use

Question

I'm new to Flex/Actionscript/FlashBuilder, and I don't quite get all the organization concepts. Our teams project is primarily ASP.NET based, so it doesn't have a lot of Flex code. There hasn't really been a need for organization/reuse of common libraries. I'm adding a rather large component that has a lot of files, and I'd like to start keeping it organized for future developers.

As I see it, .NET has:

• Solution File: Points to a bunch of project files.
• Project File: Contains the actual code and dependencies.
• Namespace: Organizes code in a hierarchical manner.

In Flex, I want a hierarchy somewhat like this example:

• Car Dealership
  • Business Layer
    • Customer
    • Employee
  • UI Components
    • Advertisement
    • Window Tag
    • Car
  • Infrastructure
    • Payroll
    • Database
  • SWF Projects
    • InventoryViewer
    • CarFeatureViewer
    • CurrentFlyerViewer

In .NET, I could have a InventoryViewer Project file, and a Solution file that opened the InventoryViewer project file along with the Infrastructure.Database project file which it depends on. Alternatively, I could have a Solution file that just pointed to InventoryViewer if I didn't want to work on the Database project as well, but the dependency is still there. How does this translate to Flex code organization? I'm having a hard time telling the difference between packages, projects, and just a plain folder hierarchy. Thanks in advance.

Answer 1

When you want to mirror the solutions style view of VisualStudio, the best way to accomplish this is to create multiple projects into a 'solution' workspace.

There isn't a direct equivalent though, so don't worry about trying to see the hierarchy in the same way.

However, when you have a small workspace like this, you can build all projects in one pass, and keep the build times at a minimum.

Version control will only work well at the project level, so that can initially be a pain, instead of being able to checkout the solution in one go, you have to check out each project individually.

Regarding the difference between packages, projects and plain folder hierarchy:

• Project : A folder with Eclipse metadata (held in the folder and also in the parent workspace folder) that represents a project, projects can have multiple build targets, but only one is built at a time using the standard Run or Debug buttons, to build multiple targets in a single project, you have to use Ant or some other build tool.

• Packages : More closely related to what .net calls namespaces, however Flex has it's own concepts of namespaces, mostly relating to XML / MXML, but that's a fairly big topic so I'll avoid that. Packages must relate to the folders they are stored in, e.g.

.

package com.example.view {
    class SomeViewClass extends SomeFlexComponent {
    // .... etc
    }
}

This class would be stored in src/com/example/view/SomeViewClass.as - unlike C# class/package names and folders must match, or the compiler will throw an error.

I'm fairly sure I haven't covered everything here, so let me know if you need further clarification about any of this.

Answer 2

If you vist some of the framework sites, and view the examples, you can see how they structure their applications. Here is the source view for a program found on the Flex framework site of Mate. You can download the source and open it in FlashBuilder to get a better feel.

http://mate.asfusion.com/assets/content/examples/intranet/srcview/

Personally, when I layout a Flex app directory structure, I break it up into "wings" based on views. Of course there is a shared directory for things that are shared. So for your example I would lay it out like this.

Car Dealership
*inventory
--views (views pertaining to the inventory )
--components (components pertaining to the inventory ) --events
--presenters
--services

The advantage of this is that it allows for modularity, so you don't have to load the entire application at once.