|
-
Custom Packages?
I'm very familiar with Flash, but new to Flash CS3 and actionscript 3.0. I have two files called Test.fla and Test.as. In Test.fla I entered 'Example.Test' in the Document class box in the properties window. The Test.as code is below:
Code:
package Example {
import flash.display.MovieClip;
public class Test extends flash.display.MovieClip {
public function Test() {
trace("Testing");
}
}
}
I get the following error: "A definition for the document class could not be found in the classpath, so one will be automatically generated in the SWF file upon export."
When I remove the package name 'Example' from Test.as changing it to look like the code below, and changing the Document class in Test.fla to Test (instead of Example.Test), everything works fine.
Code:
package {
import flash.display.MovieClip;
public class Test extends flash.display.MovieClip {
public function Test() {
trace("Testing");
}
}
}
My question: What am I doing wrong? I want to make custom packages but can't figure out how to do it. I don't want to use just unnamed packages. Thank you in advance for any help you can give.
-
OOP is one letter from OOPS
ok a package matches a folder name so to find this Test.as would have to be inside of a folder named Example that is in the class path.
-
Thanks kortex for your quick response. I changed the folder holding Test.as and Test.fla to Example, and then tried it again with the same result. So, the folder and package are now named the exact same, and that didn't help. Is that what you meant for me to do?
-
Okay, I think I have it. The .as files with a specific package name have to be in a folder by themselves, and that folder has to be the name of the package. The .fla file must be outside of that folder.
-
Code:
project_folder/
main.fla
com/
pack/
Main.as
Helper.as
caurina/
Tweener.as
Packages reflect the directory structure in relation to the source fla file, and the filename is in turn reflective of the Class name. For example, the document class here would be com.pack.Main (com.pack being the package, Main, being the class), and that class would import com.pack.Helper, and com.caurina.Tweener. Once imported, you can then just use the Class name - Tweener.addTween(...), addChild(new Helper());
-
Thanks for that clear explanation - very helpful. If I wanted more than one package could I set it up like the following, and have the packages talk to each other?
Code:
project_folder/
main.fla
com/
pack1/
Main.as
Helper.as
pack2/
Main.as
Helper.as
-
You could definitely set up different directory structures like that...although I'm not sure what would happen if you used the same name for Classes in each one - I suspect it would error. But change that and it should be fine...you can also do sub-folders deeper inside your package:
Code:
project_folder/
main.fla
com/
pack/
Main.as
Helper.as
events/
CustomEvent.as
caurina/
Tweener.as
-
You actually can use the same class names. But to differentiate them if you use both in one class you will want to use the fully qualified name.
Code:
public var p1:com.pack1.Helper;
public var p2:com.pack2.Helper;
Note that the naming convention of packages makes these names nonsensical, unless you actually own the domains pack1.com and pack2.com.
If you don't want to name your packages by domain (and you really don't need to unless you're distributing them to others), just leave off the com.
-
OOP is one letter from OOPS
-
Okay, I get it now. I didn't realize the folder names reflected domain names. That makes sense, so you don't have conflicting names with another developer. While we are discussing it...do most developers use more than one package to organize their code, or is it normal just to keep one package for the entire project?
-
I usually create a nested package structure with a top level for the project, and sublevels for the various logical sections: ui, utils, gameEngine, etc.
-
OOP is one letter from OOPS
Well the idea behind putting things in a class path and into packages is that you are creating reusable code that goes beyond the scope of a single project (at least that's the theory). The packages are supposed to group related classes together. So for example for the open source project I started (but have done next to nothing with in some time) I did the following:
com
* vfd
o ads
o animation
o collections
o media
o timers
o utils
o xml
Many of the packages are currently empty as I created them based on ideas I had for future development.
So really all of this is just a method of organization. As 5TonsOfFlax said, if you are going to be the only one using them, then organize them in whatever way works best for you.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|