The product files implementation is pretty good. However, I think it is too tied into a "file" being something on disk.
First, one needs to abstract out the files to use hook/implementations instead of relying on the fact that the file is on disk. "File" is an abstract term. The "file" could be an S3 file, etc. The common element of a file though is a stream and/or path to the data. Weather that path comes as a web url, s3 url, of path on a disk does not matter.
With that said, I am going to modify the product-files module to do this. Instead of looking on disk, it will file uc_file_hooks of some sort ( thinking hook_uc_files_api or something )to let other modules know what is going on, and let them act appropriately. Each module will show as a "drop down" with its title, and then will thus show its attributes that are needed for that type of file.
Thus, after that patch, on the attributes screen, one would see a drop down saying:
- "On Disk" ( the current implementation )
- "S3"
- "Network"
...etc.
I'll post a patch and write up on this soon.
I think this may have been one of the original desires for the file downloads module... will be interested to see what you come up with. 
I would also chime in to say that this is a good idea - it would open the door for people to sell other intangible items that could be tied to nodes. Job postings, for instance. Looking forward to your work, souvent!
Patch is just about done.
Bascially, uc_file has turned into a very then "catalog". Just holds an ID, and reference information to load more inforamtion about a "file" from the appropriate module (think how nodes are setup).
1 problem though...the drop down shows the availiable options. So when the form is shown, it says: "Select a type" from the drop down. When you select a type, the form elements are dynamically loaded.
However, when the form is submitted, none of the dynamically loaded form elements are there? Anyone give any insight? I thought we could load dynamic elements. Heck, it's how check works when you select a type of payment.
Insight is appreciated .
- Earnest
Yeah, unfortunately for dynamically loaded elements you have to look for them in $_POST directly on the form submission. I've heard this is bad practice, and it's certainly not ideal, but it's unavoidable unless we want to implement our own D6 styled AHAH stuff to the 1.0... which probably won't happen. 
Lemme know if you aren't seeing the info in $_POST either.
Yeah, it was in the post. Intead though, I found another work around that still satisifes Drupal's need to have the form structure match when it sent out, but still be dynamic, and not have to look at $_POST, and just use the usual FAPI suspects (hook_submit, _validate, etc.).
- Earnest
Should I be doing patches off of the drupal.org rc5 release?
RC5 would probably work, but going off the Bazaar version would be better.
I'm excited for this module. So by amazons3 file, you mean a url to a file hosted via amazon? (or any "url" for that matter)
Descott,
"Any" url. When I mentioned that, it was more from a low-level "API Abstraction" level. Meaning, that all uc_file does now is ask the appropriate module or a "link" (think stream) to the file, and then that is displayed to the user.
This means that uc_diskfile displays returns a direct link to the file. A uc_amazons3 displays a link to the amazon file, or perhaps a tokenized url and redirects to the amazon file (this is to better hide the direct link to the amazon file ). Etc. etc.
Hey, sorry, i became distracted with some projects.
Here's a *ROUGH* draft of the updated uc_file.
Included/attached is a uc_file patch to patch the current uc_files module.
Also included is a "uc_diskfile" module that implements the "default" implementation of files on disk.
I still need to add the last component, which is an abstraction of when a file is called for, the module presents a link, and then the module takes care of "transfering" the file. Look for that to come soon.
Then I'd love some comments and then perhaps get this into core? Pretty please with sugar on top? .
Again, there is still some MAJOR work to be done on this module/patch, so I'm looking for early feed back.
- Earnest
P.S. Oh, and I need to test an "upgrade path" for those that have uc_files implemented. This should be too hard as the upgrade should/will only involved placing the implemented uc_files to use the uc_diskfile instead.
| Attachment | Size |
|---|---|
| uc_file_patch.patch | 121.08 KB |
| uc_diskfile.zip | 2.13 KB |