I'm not sure what you are asking. I often need a concrete example.
The mod I'm still hoping to have finished later today, will allow one upload, but should be easily modified to allow an unlimited number.
The problem is what is the layout scheme. Let me explain.
Everyone is going to want to lay out the physical files differently. For each specific purpose, it might make sense to have a custom layout scheme. The problem is, in developing a utility (especially the first few releases of it) this sort of flexibility makes debugging impossible, and adds layers of complexity that may only affect a few people.
In working with this over the years (since 1984) I have distilled the physical file layout problem down to 2 or perhaps 3 different systems, which should suffice for over 90% of all the installations. There may only be 1% that need (or have a good need for) a different system.
The first system:
1) One upload directory for images, accessed via LinkID.ext, with the ability to break it down into sequences to allow for faster directory searches (transparent to the webmaster). Good for smaller systems, or where there are few graphics in the larger scheme of things.
2) One upload directory for "users" where images are stored according to user name, in nested subdirectories the way mail and Unix home pages are done. The files are found <%upload_dir%>/a/<%Username%>/LinkID.ext. Good for systems with lots of activity, where some users may upload many images, and want to have reasonable access to their stuff -- and some sort of easy webmaster organization for copyright or archival reasons.
3) Multiple directories where images are stored _in_ the category layout itself, where an image uploaded to /category/x/y/z is stored in the folder /category/x/y/z. Great for a postcards site, where the link _IS_ an image. (This also allows for "unlinked" directories where large file bases external to the server can be read in as well....)
But, those are the three main systems. If you have another one, I'm always interested, _BUT_ before going into it, think about if the image-management is an application specific thing, or site-wide thing. What that means, is a banner system would want to group images completely differently, and would therefore have to hook into the upload system, and move the files around itself.
The systems I'm looking at are for standard installs, site-wide. Not "application specific" storage.
Make sense??
It makes sense for each link to have one associated file (a graphic) that can be in one group directory.
It makes sense for each link to have several associated files that can be stored in one group directory or a subdirectory for those files.
It makes sense for each user to have an upload directory where their links grab their files, such that each file is associated with a userID or name.
It makes sense for a large gallery, image management system to flexibly allow arbitrary storage on a disk, and let the interface link to them.
It does not make sense to allow each link to have two files attached, one that goes to sub-folder A and one that goes to sub-folder B. That is an "application" or custom modification of the basic system.
The upload system I've got can do that based on file type -- ie Ascii files go to one upload directory and binary go to another, but that is probably the limit of this that will be "standard."
Any "tighter" modifications will inevitably disable some code, which makes such mods site-specific.
PUGDOGŪ PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ