Re: Package stratagies (are there some?)
Re: Package stratagies (are there some?)
- Subject: Re: Package stratagies (are there some?)
- From: Robert Walker <email@hidden>
- Date: Wed, 16 Mar 2005 14:58:50 -0500
1. Do folks even use packages ? or do most people put everything in
the default package?
Yes it is a good idea to use package for all classes. I don't always
do it for simple WO applications, but if you ever need to access
classes that are in the default package then you must do it anyway.
If you put all classes in packages you will need to change the default
file structure after creating your project. You will need to put all
your WO components inside a subfolder in the file system. What I do is
create the directory structure like this:
Project Wrapper Directory
---BusinessLogic
---Common // If using JavaClient
---Server // If using JavaClient
---Client // If using JavaClient
---Classes
---Components
---Resources
---WebServerResources
---Interfaces
---Documentation
Then I point my Xcode groups directly to the corresponding folders. Do
this by selecting the group in the list, open the inspector panel and
use the [Choose...] button to select the proper directory. Then any
files that are added from [Add to Project...] menu or dragged in will
be copied to the correct subfolder in the file system.
You may get errors if you leave your WOComponent java files in the root
of the project directory.
Also you will need to move your EOModel files into the BusinessLogic
subfolder where your business objects live. This is due to a goofy bug
the current version of EOModeler. If the class files are not in the
same directory as the model file you never get the "Merge" option when
generating your EO classes. I really hope Apple fixes this in the next
release.
Once you structure your project and update all your file references in
the Xcode project. Then you can create your package structure any way
you want. I like to just throw everything in a single package
representing my application.
For JavaClient I create three packages if the form:
com.mycompany.common, com.mycompany.server, & com.mycompany.client.
Common classes that work on both the server and client side can be
added to both Applcation Server & Web Server targets and placed in the
common package.
Basically I prefer to keep things a simple as possible. The only time
I build more complex package structures is when I plan to build classes
as a API for others to extend. This is especially true when building
framework projects.
2. There is no importing a class from the default package since in
JDK 1.4 , so references to this practice in the mail archives must be
from an earlier time, right? (It doesn't work for me.)
You shouldn't have to import anything that is in the default package.
It's automatically available.
As mentioned above this is no longer true since JDK 1.4. You cannot
access classes in the default package from a class that is in a
package.
On Mar 16, 2005, at 2:13 PM, Colin Clark wrote:
1. Do folks even use packages ? or do most people put everything in
the default package?
Yes, I expect that most people definitely use packages. There's no
reason not to, and they're a great way to clearly partition your code.
2. There is no importing a class from the default package since in
JDK 1.4 , so references to this practice in the mail archives must be
from an earlier time, right? (It doesn't work for me.)
You shouldn't have to import anything that is in the default package.
It's automatically available.
3. What EO/WO references need to specify the qualified-with-package
class name besides the EOModeler Class specification?
As you say, the class name for your entities should be the fully
qualified version (eg. my.package.Class). You do need specify the
fully-qualified name of your WOApplication subclass by defining the
WOAPPLICATION_CLASS_NAME variable in your project's target in XCode.
4. Any other "gotchas" in reference to this?
Nope, it's pretty straightforward. I've never had any problems related
to packages. Keep in mind that if you don't define package membership
for all your classes, you'll likely run into difficulties if you
eventually choose to deploy your application as a servlet.
Colin
---
Colin Clark
Dynamic Web and Database Development Lead,
Resource Centre for Academic Technology,
University of Toronto
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
--
Robert Walker
Bennett Technology Group
(770) 957-1866 Ext: 790
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden