On my local machine, I want my home directory and my web directory to be identical. Any file in my home directory is also available on the web (possibly possibly by a password). I prefer to group my files by object, such as a research project on deconvolution, or my private stuff.
Since an applet only offers two entries to the server file system - the document base and the code base URL - all files relevant to that applet have to be named relative to these two entries. This is comparable to having a executable path that only accepts a single directory. Since my various projects in some cases overlap, I have to organize all files in a single, large file hierarchy. If the code base and document base arguments were to accept a directory path, I could organize my files in more manageable smaller object-oriented groups.
Given these limitations and preferences, here is the directory structure I came up with after some thought and experimentation:
ij: gui: io: plugin: process: ijDoc: plugs: paper: imageJ: ipDemo: reFig: Fig:The ij directory contains all the files I received from NIH. The ijDoc directory contains all the files I wrote. (I did not write imageJ and ipDemo but I modified them to a degree that I wanted to ensure that they are not being lost when I up-date the ij image software.) This allows for smooth up-dates of the NIH software and adheres to my principle to group files by object (this case authorship) not file type.
The subdirectory ijDoc/plugs includes all the SEP specific Java applications such as a simple handler of SEP data structures and the NMO application. The subdirectory ijDoc/reFig contains the html page that describes the NMO process and the applet that invokes the NMO example. The code base is defined as ../... which is the relative path to the correct parent directory. All Java programs are named relative to that code base: so the full NMO applet name is ijDoc.reFig.ReFig.java. Keeping track of these names and the relative path name is the price I pay for an object oriented filing system compromised by a single code base.
The ij.properties file lists plug-ins and other resources that ImageJ should offer to the user. The ij.properties file has to be in the document base directory of the ImageJ invoking applet. I wish the name of that property file could be a parameter argument in the applet tag. A single HTML file could include numerous applets each with its individual property file. This would allow an author to guide the reader by customizing imageJ for each individual image.
ImageJ contains four methods to locate images and data. All of them are found in the File pull down menu. The New button creates a synthetic data set (e.g. a white image) and works as soon as ImageJ works. The Open ... button gives you a file dialog window that allows you to locate an image file (gif, jpeg) somewhere on your local file system. I am not sure how the button works, if you execute the applet remotely. For remote execution you have the Open button without dots. When pressed the button offers a second menu with figure names: the author of the applet defines the figure names and the path to these figures (again gif or jpeg) in the ImageJ's ij.property file. When run locally the images need to be in an subdirectory named images relative to the applet's document base. (I wish that would be a bit more flexible). Finally the Acquire button offers the user a variety of accesses and image formats: The URL option prompts the user for a URL, the Raw option gives the user a file dialog box to locate a file with floats. It will further prompt the user for pixel width and height.