On 4/3/06 3:34 PM, Darrel O'Pry wrote:
On Mon, 2006-04-03 at 09:36 -0700, Boris Mann wrote:
On 3-Apr-06, at 9:28 AM, Sean B. Fuller wrote:
But like I said, after considering all the management interface that would be needed to really make multiple images work, it seems like trying to pack this all in to image.module might be a bit much. I'd rather see the nodeapi_image functionality that I posted added to image.module, and then start a new thread about how to effectively make an embedded multi-image mini-gallery in a node. That's my two cents anyway. Thoughts? The use cases for multiple images per node are many -- and "mini gallery" is only one of them. This is indeed a case for relationships, which is a higher level issue.
Gerhard's upload_images.module associates multiple images, but only displays as thumbnails. Nodeimageblock doesn't use image nodes, but just upload files, and doesn't do resizing. My dream module would be a combination of these two, using 4.7. region to display the block of images (with configurable thumbnail size), displaying the image node title/caption and linking to a full size image.
-- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
I'm still hot on the idea of a file callback that works with the existing upload.module, and eliminating all this image.module, audio.module, media.module stuff and having plugins that react to the file lifecycle based on mime or extension....
well... yeah, I mostly agree with that. I think a lot of the "smarts" for file handling need to be offloaded into core's File "API". However, I disagree that this is instead of image/audio/etc . But I think image/audio/etc shouldn't have to do so much. But, back in the day I was trying to promote the idea of "toolkits" (which you call here "plugins") ... for exactly this reason - extracting metadata, additional file handling, etc.
Still haven't decided whether a full-on node (utilizing existing nodeapi and all the weight of node_load) or keeping files as a distinct object from nodes so they can have a lighter api and making a file<->node relationship module. I'm going to try the former first.
I think we still want nodes-level "files" ... but yeah, "direct" access to the files is absolutely required... however, there are *many* use cases where throwing out all of the "for free" features of node-level stuff seems silly. I've given my thoughts on this several times, but need to sit still long enough to write it all down. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net