Implementing a team classpath?

Question

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

Answer 1

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" <[email protected]> wrote
in message
news:[email protected]...
> 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
>