Apr 9, 2002, 3:04 PM
Veteran / Moderator (6956 posts)
Apr 9, 2002, 3:04 PM
Post #6 of 6
Views: 4928
Alex,
If there are not going to be any more changes to how Links handles attachments, or runs internally, then I might (*might*) have a multiple upload, and automatic addition program done shortly. Not being a part of GT, it's hard to know what you guys are really doing, and the past few months my time has been ever so precious when it comes to any of this.
I don't know if you remember any of my earlier posts, prior to maybe last July, where I was discussing the idea of multiple attachments, and uploads. The updated template parser has made some things easier, since the checking for attachments and the user level can now be done at display time.
One of my needed features was to be able to upload a directory, or a directory tree, and have those images (I work in mostly images) added to the database based on a set of rules. Everything that could be figured out about a file by it's physical location (directory tree), it's extension (or byte code), size, dimentions, etc would be inserted into the database. The user would have to go back and add specifics. What files it went looking for could be "plugin" (plug ins to this plugin <G>) dependent. You could, in theory, active the "images" module and then allow only GIF and JPG, but not TIF and PSD, you could plug in a PDF module, and seek out (and validate) PDF files, etc. In other words, by adding in (chaining) allowed file types, and the processing rules for each, you could add an unlimited number of allowed and screened types. Admittedly, I'm only checking GIF, JPG, PNG, DOC (word) and TXT. I'm not checking ZIP, TAR, ARC, or any other sorts of pre-grouped files, or such. But, again, in theory, the way I've been working the program, it shouldn't be hard to add -- and to generalize the add routine to be a plug-in using the plugin.cfg file to control it all. The main "add" script only needs to know if the file was good, and the attributes for that allowed file type. All bad files are handled pretty much the same way.
Additionally, I wanted to have "file groups" so that a "link" could have multiple attachments, and you could add attachments to a link by entering the LinkID (basically) and it would create the proper associations.
Reconstruction of the database was another prime need, so having "redundant" data on disk was what I was working on when everything crashed.
I'm getting close to being back up to "steam". Things have settled down, and have stayed settled for about 2 months, our retail shop has finally opened, and I'm about 70% through with reconstructing our servers.
In short, what I have is a system that uses the "Links" table as the main table for browsing through the data. Items are attached to links, and the "power" of links is used as much as possible.
I've piggybacked on to that a second table, that tracks the "attachments" similar, but more complicated, than the current links attachment table (we discussed this about that time as well). The attachments have their own approval, and admin features, separate from the Link. They use several flags -- starting with the link itself being validated, to the attachment having an isApproved flag, a ShowAttach flag, and others.
With the release of the "reviews" system, I have had to make some changes, mostly in logic, and am trying to upgrade the reviews system, and then build the "generalized" attachments off that.
Unfortunately.... this isn't my full time job (though it does seem it some times <G>) and you guys have more of a team effort going. Hopefully, though, once my internet connection is in on Thursday, and I get the machines reconnected over the weekend, it will allow me to get some stuff available for comment maybe.
I am hoping, that after this week, my life will again settle down into a boring routine for the next few years. I may be hoping for too much, but I don't think I'd survive another year like my last one.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.