2 Replies Latest reply on Jun 26, 2007 3:56 PM by Flex D

    Best Practice Directory Structure

    Flex D
      I'm new to programming and I'm creating a large application that will have a lot of pages and components. As I continue to add to the project, I find it harder and harder to easily locate the pages and components that I need to work with. To help me with this problem, I've decided to add a label to every component with the location of where it can be found. Now when I view the application and I see a component I want to work with, I know where it is located.

      This is problably not the best way to handle the problem, it will be a pain to go back and remove or comment out these when I'm fininshed with the project, but it wil help now.

      Short of having a better memory :>), is there any best practice guidelines I should look into and follow when I create my directory structure of files and components that will intuitively help me quickly locate a component? What do you use to help you?

      Thanks for your ideas and suggestions
        • 1. Re: Best Practice Directory Structure
          peterent Level 2
          There are many ways to answer this. If you have a big project you might consider using a Flex Library Project for your components - think of it as writing a set of components you (or your company) might one day sell to others - even if you never have that intent. The idea is to make the components as reusable as possible in case you need them for the next project. Having them in a separate Flex Library project (which creates a .swc file) would make that easier.

          The industry best-practice seems to be to create packages that begin with your company's domain name, but in reverse order. For example, components I write for Adobe go into a package beginning with com.adobe which works out to be the file structure com/adobe and then is further divided by the application and then its parts (eg, com.adobe.scrapbook.editor). Using your company's domain to distinguish your components enables you and others to combine components from different places without naming conflicts.

          If you divide your application into logical parts you can figure out a good package naming convention that is easier to remember. For example, I might put all of the skins for my Scrapbook Editor into the com.adobe.scrapbook.editor.skins package. I can easily find those files and add to them as necessary.

          Other people follow a similar pattern and there are books on the subject, too.
          • 2. Re: Best Practice Directory Structure
            Flex D Level 1
            Thanks for the insight. I will do some research