Search code examples
apache-flexactionscriptflash-buildercode-organizationproject-organization

Organizing a Flex Project for Team Use


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.


Solution

  • 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.