[development] nodeapi image concept (request for feedback)
walkah at walkah.net
Tue Apr 4 02:47:53 UTC 2006
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
> 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 at walkah.net
More information about the development