Ok... makes sense.
How does w3t handle them? (I've never really probed that code at all).
I can think of several ways I'd _like_ to deal with images :) (consider my use of "image" to mean "file" and vice versa).
A full file-management system in MySQL is not unreasonable. When a file is uploaded, it gets an associated LinkID. Or, it can be associated with a Category. With a category, the file is displayed via a <%files%> tag, and I guess similarly with the links, <%files%> would display any associated files.
If file management was _not_ linked to the rest of links, except by Username (absolute) or LinkID/CategoryID (absolute) then it would make a nice plug-in, and probably could be put together in short order.
Once a skelleton is formed, improvements follow.
On the build process, the files database would be searched, and the links and categories that had associated files would be updated.
That way, in a build xx_page routine, the category and links would both know already $if_attach
--
That handles attachements.
But, what most people want is the ability to upload one or more graphics and have them display with the links.
In that respect, the GRAPHIC should know where it belongs, not the link (since not all links have graphics). The link should only know _if_ it has one or more graphics attached.
There are 5 (or 8) main attributes to a graphic:
/path/name/to/graphic
height
width
size
/path/name/to/graphic/thumbnail
height
width
size
In my system,I've never separated the path and the graphic name, since for me it works that way.
But, you could. The graphic could have a 'name' then belong to a 'pool' which was a directory (or directory tree).
The program would map the 'pool' to a path,and create the /path/to/file/name
(This stems out of a photographic negative/image program I started to write waaaaay back in the Dos 2.0 days).
Logic break: The reason for this, is that rather than limit people to using one graphic as a 'logo' and the rest for 'product shots' if the graphics routines were generalized, people could locate the graphics anywhere using <%graphic_nn%> tags.
This means, as far as management goes:
A graphic database containing just the image information and name, and a "pool"
A pool database containing the upload and storage area information ie: "pools"
A means to link the graphic to a link or category (like CatLink).
It would be up to the person using the database to make sure the first uploaded image would be the "logo" if they were going to have one, and then any subsequent images would be "product" shots.
Or... add a field to the GraphicLink database that determines what that image is, within the "link" or "category" record.
ie: A person uploads 6 images and wants to associate them with a Link, they create a new GraphicLink (catlink) entry, that has the GraphicID, Link or Category ID, and the TYPE of image (an Enum type that becomes a field tag). Such as Logo, Picture1, Small_View, Interior_View, etc.
Then, in the build process, when the files/graphics are obtained, the GraphicsLink database is culled for matching Graphics and types:
Select * from GraphicLink where LinkID=9
There is then a list of files generated, and they can be listed with the <%files%> tag all together, or individually by their GraphicsLink.Type field name.
This way, the same graphic can be used in many links or categories, with only one graphic database entry, but multiple GraphicLink entries.
When a graphic is moved from one "pool" to another, it's copied [and deleted] to the new location. "pools" are locations, graphic directories, etc.
A graphic only needs to know where it's located, and it's atrributes. The link and category records should decide how and where to use it.
PUGDOGŪ PUGDOGŪ Enterprises, Inc.
FAQ: http://postcards.com/FAQ
