2 Replies Latest reply on May 18, 2006 7:16 AM by funkDaddyFlash

    implementing a team classpath?

    funkDaddyFlash
      I'm on a team of 3 developers who are looking at Flex as one of our new development environments.

      Working with it, I created a custom (mxml) component. For argument's sake, let's call it "MyComponent". I want to have an area that ALL the code we write in the future can reference, so I set up a folder on our file server and set up the class path (source path) to point to it. Cool.

      Trying to be organized, I made a folder tree inside that main folder : com >> mycompanyname >> coolthings. Now to use MyComponent in an MXML file, I set up a namespace like this:

      <mx:Application xmlns:mx=" http://www.adobe.com/2006/mxml"
      xmlns:test="com.mycompanyname.coolthings.*">

      and can now call my component like this in that MXML file

      <test:MyComponent id="cool" />

      Again. Good.

      Here's where I'm getting to think I'm not doing something right. If I make other organizational folders as SIBLINGS of the coolthings folder (like imagethings, formatterthings, buttonthings), it seems that I would need to create separate namespaces in every MXML file that uses them, once for each area of the (package? - I'm new to a lot of the OOP, so I may not be using the right terms...)

      So, could anyone tell the the "right" or "best" way to do it? I want that folder of all our custom components to stay organized so that we can finds stuff in there once we have a few hundred components, but at the same time, it seems like I'm dooming myself to have 50 namespaces in a document if I use compnents from 50 different areas of that structure.

      Maybe something with import statements or a way to say that one namespace holds the ENTIRE mycompany folder so it will find the subfolders? Or am I doing sometihng totally wrong.

      Thanks. I'm a newbie.

      -- TC
        • 1. Re: implementing a team classpath?
          Level 7
          Hello -

          What you want to look into is declaring a manifest file. Manifest files map
          a component namespace to class names. They define the package names that the
          components use before being compiled and they help keep your source files
          organized. The documentation has a whole section dedicated to using manifest
          files and the syntax that they follow in the MXML Compiler section, so
          please check that out.

          The package-based namespace format has been around since Flex 1.0. Its a
          legacy format that we decided to keep for quick prototyping without setting
          up a manifest file. You are correct to point out that when you start putting
          lots of components in a broad/deep hierarchy you will run into namespace
          problems - but that signals the right time to organize the component with a
          manifest file :)

          Best,
          Deepa Subramaniam
          Flex SDK Developer

          "funkDaddyFlash" <webforumsuser@macromedia.com> wrote in message
          news:e4fr5u$s7j$1@forums.macromedia.com...
          > I'm on a team of 3 developers who are looking at Flex as one of our new
          > development environments.
          >
          > Working with it, I created a custom (mxml) component. For argument's
          > sake,
          > let's call it "MyComponent". I want to have an area that ALL the code we
          > write
          > in the future can reference, so I set up a folder on our file server and
          > set up
          > the class path (source path) to point to it. Cool.
          >
          > Trying to be organized, I made a folder tree inside that main folder : com
          > >>
          > mycompanyname >> coolthings. Now to use MyComponent in an MXML file, I
          > set up
          > a namespace like this:
          >
          > <mx:Application xmlns:mx="<a target=_blank
          > class=ftalternatingbarlinklarge
          > href=" http://www.adobe.com/2006/mxml"
          > xmlns:test="com.mycompanyname.coolthings.*">
          >
          > and"> http://www.adobe.com/2006/mxml"
          > xmlns:test="com.mycompanyname.coolthings.*">
          >
          > and</a> can now call my component like this in that MXML file
          >
          > <test:MyComponent id="cool" />
          >
          > Again. Good.
          >
          > Here's where I'm getting to think I'm not doing something right. If I
          > make
          > other organizational folders as SIBLINGS of the coolthings folder (like
          > imagethings, formatterthings, buttonthings), it seems that I would need to
          > create separate namespaces in every MXML file that uses them, once for
          > each
          > area of the (package? - I'm new to a lot of the OOP, so I may not be using
          > the
          > right terms...)
          >
          > So, could anyone tell the the "right" or "best" way to do it? I want that
          > folder of all our custom components to stay organized so that we can finds
          > stuff in there once we have a few hundred components, but at the same
          > time, it
          > seems like I'm dooming myself to have 50 namespaces in a document if I use
          > compnents from 50 different areas of that structure.
          >
          > Maybe something with import statements or a way to say that one namespace
          > holds the ENTIRE mycompany folder so it will find the subfolders? Or am I
          > doing sometihng totally wrong.
          >
          > Thanks. I'm a newbie.
          >
          > -- TC
          >


          • 2. Re: implementing a team classpath?
            funkDaddyFlash Level 1
            Perfect. Just what I was looking for. Thanks!

            -- TC