nodeapi image concept (request for feedback)
Hey all, I’ve recently been working on a nodeapi-based image upload module for 4.7. I saw some conversations on this list a few weeks ago concerning efforts to unify image-handling projects and I was wondering how such a project would fit with these efforts. The image_nodeapi module currently has the following functionality: - Settings page to determine which nodes should enable image uploads. - Uses the image functions image_prepare, image_insert and image_update to do all the heavy lifting. - Allows users to set a caption for the image. - Default layout of a floated right image with the caption displayed underneath the image on pages. - Passes the node object to the theme, allowing site admins to over-write presentation of images to fit site specific needs. - Along these lines, admins could use a case statement in their theme file that would display a different layout for different node types, etc. The whole thing weighs in at just over 200 lines of code with a custom table for the captions and a css file to handle the default layout. Would the community be interested in a module like this? I’m willing to share the code with any who would like to review it. Please note that I don’t have write access to the contributions cvs repository. If the community thinks this module would be useful, I'll formalize my application in order to add this as a contributed module. If there are other projects that are about to surface that are similar to this, I'm definitely willing to combine efforts. I'll create a forum topic on drupal.org with posted code if that is the suggested way to proceed. As this is our first attempt to give back to the drupal community, any suggestions on the best way to proceed are welcome. Thanks, Sean B Fuller seanbfuller.com tractiv.com ps- About me: I'm a developer for Tractiv (http://tractiv.com) and we've been using drupal for several projects. One of our most recent is the Chicago Artists Resource (http://www.chicagoartistsresource.org), which went live at the end of 2005.
Hi Sean, As image.module maintainer - this is exactly one of the features I'm looking at this functionality and making it part of image.module. I think your description sounds excellent. Feel free to either post the code or send it to me offlist . Cheers! James On 31-Mar-06, at 3:09 PM, Sean B. Fuller wrote:
Hey all,
I’ve recently been working on a nodeapi-based image upload module for 4.7. I saw some conversations on this list a few weeks ago concerning efforts to unify image-handling projects and I was wondering how such a project would fit with these efforts.
The image_nodeapi module currently has the following functionality:
- Settings page to determine which nodes should enable image uploads. - Uses the image functions image_prepare, image_insert and image_update to do all the heavy lifting. - Allows users to set a caption for the image. - Default layout of a floated right image with the caption displayed underneath the image on pages. - Passes the node object to the theme, allowing site admins to over- write presentation of images to fit site specific needs. - Along these lines, admins could use a case statement in their theme file that would display a different layout for different node types, etc.
The whole thing weighs in at just over 200 lines of code with a custom table for the captions and a css file to handle the default layout.
Would the community be interested in a module like this? I’m willing to share the code with any who would like to review it.
Please note that I don’t have write access to the contributions cvs repository. If the community thinks this module would be useful, I'll formalize my application in order to add this as a contributed module. If there are other projects that are about to surface that are similar to this, I'm definitely willing to combine efforts. I'll create a forum topic on drupal.org with posted code if that is the suggested way to proceed.
As this is our first attempt to give back to the drupal community, any suggestions on the best way to proceed are welcome.
Thanks,
Sean B Fuller seanbfuller.com tractiv.com
ps- About me: I'm a developer for Tractiv (http://tractiv.com) and we've been using drupal for several projects. One of our most recent is the Chicago Artists Resource (http://www.chicagoartistsresource.org), which went live at the end of 2005.
-- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
James Walker wrote:
Hi Sean,
As image.module maintainer - this is exactly one of the features I'm looking at this functionality and making it part of image.module.
I think your description sounds excellent. Feel free to either post the code or send it to me offlist .
Sean - please send it to the list. James can grab it from there. Others will want this too. I encourage you to pursue it further and contribute it to CVS repository. It isn't that hard to get access and manage CVS. There are docs in the handbook for this ... You module sounds useful.
I've posted the code here: http://drupal.org/node/56761 I'll apply for cvs contrib write access in just a few. In the meantime, Walkah, let me know if you would rather have this in image.module or as a separate, helper module. -sean Moshe Weitzman wrote:
Sean - please send it to the list. James can grab it from there. Others will want this too. I encourage you to pursue it further and contribute it to CVS repository. It isn't that hard to get access and manage CVS. There are docs in the handbook for this ... You module sounds useful.
There's an issue on the image module for moving to nodeapi: http://drupal.org/node/43628 And a somewhat similar module draft some time back: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/jareyero/modules/...
On 31-Mar-06, at 5:25 PM, Nedjo Rogers wrote:
There's an issue on the image module for moving to nodeapi:
Yeah, after looking through the code, I'm inclined to say this makes sense directly in image.module . Do others have a strong opinion? -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
I'd like to see it there On 4/2/06, James Walker <walkah@walkah.net> wrote:
On 31-Mar-06, at 5:25 PM, Nedjo Rogers wrote:
There's an issue on the image module for moving to nodeapi:
Yeah, after looking through the code, I'm inclined to say this makes sense directly in image.module . Do others have a strong opinion?
-- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
I think it's exactly what a lot of people have been asking for in image.module for a long time -- definitely more useful for the majority of people than the gallery function. Like uploading, it can be turned off on a nodetype by nodetype basis, so nothing is *forced* on users, neh? I'm curious whether it could be used by a module I'm working on -- a 'graphic novel' nodetype that would have 2 explicitly named images associated with it (one for the left page and one for the right page of a two-page spread). --Jeff -----Original Message----- From: James Gilliland [mailto:neclimdul@gmail.com] Sent: Sunday, April 02, 2006 12:36 PM To: development@drupal.org Subject: Re: [development] nodeapi image concept (request for feedback) I'd like to see it there On 4/2/06, James Walker <walkah@walkah.net> wrote: On 31-Mar-06, at 5:25 PM, Nedjo Rogers wrote:
There's an issue on the image module for moving to nodeapi:
Yeah, after looking through the code, I'm inclined to say this makes sense directly in image.module . Do others have a strong opinion? -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
+1 from me. Jeff Eaton wrote:
I think it's exactly what a lot of people have been asking for in image.module for a long time -- definitely more useful for the majority of people than the gallery function. Like uploading, it can be turned off on a nodetype by nodetype basis, so nothing is *forced* on users, neh?
I'm curious whether it could be used by a module I'm working on -- a 'graphic novel' nodetype that would have 2 explicitly named images associated with it (one for the left page and one for the right page of a two-page spread).
--Jeff
-----Original Message----- *From:* James Gilliland [mailto:neclimdul@gmail.com] *Sent:* Sunday, April 02, 2006 12:36 PM *To:* development@drupal.org *Subject:* Re: [development] nodeapi image concept (request for feedback)
I'd like to see it there
On 4/2/06, *James Walker* <walkah@walkah.net <mailto:walkah@walkah.net>> wrote:
On 31-Mar-06, at 5:25 PM, Nedjo Rogers wrote:
> There's an issue on the image module for moving to nodeapi: > > http://drupal.org/node/43628
Yeah, after looking through the code, I'm inclined to say this makes sense directly in image.module . Do others have a strong opinion?
-- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net <mailto:xmpp:walkah@walkah.net>
At the same time I would also separate out the gallery portion of the code; perhaps making it a separate module (image.module + image_gallery.module) which would allow alternative galleries (shazamgallery for example) to have more freedom without worrying about the default image gallery stuff. Taxonomy is not always appropriate for galleries. Jeff Eaton wrote:
I think it's exactly what a lot of people have been asking for in image.module for a long time -- definitely more useful for the majority of people than the gallery function. Like uploading, it can be turned off on a nodetype by nodetype basis, so nothing is *forced* on users, neh?
I'm curious whether it could be used by a module I'm working on -- a 'graphic novel' nodetype that would have 2 explicitly named images associated with it (one for the left page and one for the right page of a two-page spread).
--Jeff
-----Original Message----- *From:* James Gilliland [mailto:neclimdul@gmail.com] *Sent:* Sunday, April 02, 2006 12:36 PM *To:* development@drupal.org *Subject:* Re: [development] nodeapi image concept (request for feedback)
I'd like to see it there
On 4/2/06, *James Walker* <walkah@walkah.net <mailto:walkah@walkah.net>> wrote:
On 31-Mar-06, at 5:25 PM, Nedjo Rogers wrote:
> There's an issue on the image module for moving to nodeapi: > > http://drupal.org/node/43628
Yeah, after looking through the code, I'm inclined to say this makes sense directly in image.module . Do others have a strong opinion?
-- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net <mailto:xmpp:walkah@walkah.net>
I agree, gallery is not really core material, but uploading images and using them on various pages is. To use them they need to be browsable by various mechanisms, e.g. owned by current user or taxonomy. Images need copyright restrictions, e.g. by user, public domain, creative commons, that get assigned at upload time.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Earl Miles Sent: Sunday, April 02, 2006 4:37 PM To: development@drupal.org; jeff@viapositiva.net Subject: Re: [development] nodeapi image concept (request for feedback)
At the same time I would also separate out the gallery portion of the code; perhaps making it a separate module (image.module + image_gallery.module) which would allow alternative galleries (shazamgallery for example) to have more freedom without worrying about the default image gallery stuff. Taxonomy is not always appropriate for galleries.
Jeff Eaton wrote:
I think it's exactly what a lot of people have been asking for in image.module for a long time -- definitely more useful for the majority of people than the gallery function. Like uploading, it can be turned off on a nodetype by nodetype basis, so nothing is *forced* on users, neh?
I'm curious whether it could be used by a module I'm working on -- a 'graphic novel' nodetype that would have 2 explicitly named images associated with it (one for the left page and one for the right page of a two-page spread).
--Jeff
-----Original Message----- *From:* James Gilliland [mailto:neclimdul@gmail.com] *Sent:* Sunday, April 02, 2006 12:36 PM *To:* development@drupal.org *Subject:* Re: [development] nodeapi image concept (request for feedback)
I'd like to see it there
On 4/2/06, *James Walker* <walkah@walkah.net <mailto:walkah@walkah.net>> wrote:
On 31-Mar-06, at 5:25 PM, Nedjo Rogers wrote:
> There's an issue on the image module for moving to nodeapi: > > http://drupal.org/node/43628
Yeah, after looking through the code, I'm inclined to say this makes sense directly in image.module . Do others have a strong opinion?
-- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net <mailto:xmpp:walkah@walkah.net>
On 4/2/06 4:37 PM, Earl Miles wrote:
At the same time I would also separate out the gallery portion of the code; perhaps making it a separate module (image.module + image_gallery.module) which would allow alternative galleries (shazamgallery for example) to have more freedom without worrying about the default image gallery stuff. Taxonomy is not always appropriate for galleries.
yup. this is already in the works. :) -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
Op zondag 2 april 2006 22:37, schreef Earl Miles:
At the same time I would also separate out the gallery portion of the code; perhaps making it a separate module (image.module + image_gallery.module) which would allow alternative galleries (shazamgallery for example) to have more freedom without worrying about the default image gallery stuff. Taxonomy is not always appropriate for galleries.
There is already great code for all this! image.module as image/node API system. » http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/robrechtj/image/ Bèr
I'm definitely cool with the image upload functionality going into image.module. I've already had five requests for multiple images since I posted the code on Friday and I think it would definitely be a good feature, but this might be a job for a different module. At first glance, it seems like this would require a different relational scheme. The nodeapi_image code is based on the same logic as image.module, where each node gets one image. Trying to pack multiple images into the images array could prove messy. As an alternative, allowing several different images might be done by making each image its own node and creating a relation between the parent node (the page) and the children (its images). It would require some sort of interface, perhaps on a "mini-gallery" tab, where you could set the weight of each image, delete images, add images, replace images, change the captions, etc. Submitting this page would then perform a batch save/update/delete of the image nodes and update the relational table for parents and children. The end result might be a nice row of thumbnails that the user could click on and browse through as a sort of mini-gallery. Imagine clicking on a thumbnail and getting a preview-sized image, a caption, a link back to the page view, a previous image link, and a next image link. The above description sounds similar to functionality that already exists in other modules, so it seems possible. 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? -sean
I think it's exactly what a lot of people have been asking for in image.module for a long time -- definitely more useful for the majority of people than the gallery function. Like uploading, it can be turned off on a nodetype by nodetype basis, so nothing is *forced* on users, neh?
I'm curious whether it could be used by a module I'm working on -- a 'graphic novel' nodetype that would have 2 explicitly named images associated with it (one for the left page and one for the right page of a two-page spread).
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
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.... 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.
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
On 3-Apr-06, at 7:47 PM, James Walker wrote:
I've given my thoughts on this several times, but need to sit still long enough to write it all down.
I think we're almost ready to start hosting special interest groups / DEP working groups on groups.drupal.org -- I hear a File API one and an Image one... -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
On Mon, 2006-04-03 at 22:47 -0400, James Walker wrote:
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 think I can be persuaded to the node-level file concept. I'd really want to hear ideas about asynchronous node creation, node/filesystem consistency, loading data about 10's-100's of files at once (file browser), flexible attributes table... (specific to files or to all nodes?, like old serialized storage but queryable), clean handling of preview states with file nodes.(I'd personally like to remove the concept of a file preview altogether, you either upload it or don't. I don't like 'file limbo' and I think it is a confusing UI and development paradigm. Look at the hoops we currently jump through to support files in previews, and the difficulties it has caused with validation and open_basedir that could be completely eliminated by removing the idea of a file in a preview state.) It would be nice to take advantage of the existing node_access system and nodeapi. It would also bring more focus on making a node a universal concept. I would also like to have files owned by users and simple associated to a node, which is implicit with the files as a node concept.
I've given my thoughts on this several times, but need to sit still long enough to write it all down.
I'd really appreciate the input if you can find the time. I keep putting thought into this, but I am undertaking the effort for my own projects. I would like the work I do to be useful for the community as a whole and not be limited by my shortsightedness and focus on my own goals. .darrel.
Darrel O'Pry wrote:
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 prefer the approach of keeping files separate from nodes, because for my use-cases files are usually not the actual content of the site.. files are uploaded to be used in other content. Rich metadata is definitely needed. There are many properties that files could have that nodes do not... but I suppose that could all be kept in a separate lookup table keyed on file_id or node_id and it wouldn't really matter. Now, the idea of having files separate, and then maybe being able to "convert" a file to a node would make sense to me in the rare cases that the file you've uploaded is actually meant to be the content.
Op dinsdag 4 april 2006 23:48, schreef Rowan Kerr:
Rich metadata is definitely needed. There are many properties that files could have that nodes do not... but I suppose that could all be kept in a separate lookup table keyed on file_id or node_id and it wouldn't really matter.
My opinion: Drupal: * anything that comes with metadata is a node. * Nodes are NOT equivalent of posts So yes, I think that having some 'any file is a node too' concept is a very, very good idea. All we would need then, is some simple node->type = foo to node->type = image relation system (do I hear relations?) to add your images to any content. -- [ Bèr Kessels | Drupal services www.webschuur.com ] Hoe het naviatie blok te verbergen: http://help.sympal.nl/hoe_het_naviatie_blok_te_verbergen
On 4-Apr-06, at 2:48 PM, Rowan Kerr wrote:
Darrel O'Pry wrote:
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 prefer the approach of keeping files separate from nodes, because for my use-cases files are usually not the actual content of the site.. files are uploaded to be used in other content.
Rich metadata is definitely needed. There are many properties that files could have that nodes do not... but I suppose that could all be kept in a separate lookup table keyed on file_id or node_id and it wouldn't really matter.
There are clearly two separate use cases (files only vs. files as nodes) -- but, we really have to support both nicely.
Now, the idea of having files separate, and then maybe being able to "convert" a file to a node would make sense to me in the rare cases that the file you've uploaded is actually meant to be the content.
It would be great if people could clearly define and *write down* their use case, rather than saying "there is no way I need that". We're working on groups.drupal.org for potentially doing special interest groups as well as user group meet ups. I think walkah has a sample File API group set up there...bug him if you're interested. Cheers, -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
On Tue, 2006-04-04 at 15:07 -0700, Boris Mann wrote:
On 4-Apr-06, at 2:48 PM, Rowan Kerr wrote:
Darrel O'Pry wrote:
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 prefer the approach of keeping files separate from nodes, because for my use-cases files are usually not the actual content of the site.. files are uploaded to be used in other content.
Rich metadata is definitely needed. There are many properties that files could have that nodes do not... but I suppose that could all be kept in a separate lookup table keyed on file_id or node_id and it wouldn't really matter.
There are clearly two separate use cases (files only vs. files as nodes) -- but, we really have to support both nicely.
I would prefer it be transparently, personally. I really dislike the concept of two different core API's for handling files in different ways. It makes my ears twitch. My personal opinion is that if a full scale file as node works for everyone we do it that way. If we NEED a lighter file handling system, we make a lighter file api, and a wrapper that allows a file to be a node. So you can access it through the API directly or as a filenode. The concept is much like the current split between upload.module and file.inc, only we sink much of upload into file.inc (all the file db and os level file handling, and file lifecycle hooks/callbacks)... And make the filenode higher level wrapper...
Now, the idea of having files separate, and then maybe being able to "convert" a file to a node would make sense to me in the rare cases that the file you've uploaded is actually meant to be the content.
It would be great if people could clearly define and *write down* their use case, rather than saying "there is no way I need that".
I need to be able to: -Mass upload files to a site. -Manage files through a tradition filebrowser style interface. -Easily integrate with the common drupal file handle. -Interact with the file lifecycle. (create derivatives(thumbnails), detect and store metadata, etc)... -More fine tuned file permissions. -Handle large file uploads (ftp interfaces that integrate with drupal, etc) -extension specific theming
We're working on groups.drupal.org for potentially doing special interest groups as well as user group meet ups. I think walkah has a sample File API group set up there...bug him if you're interested.
If you read this Walkah I'd love to join that SIG.
Cheers,
-- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
James Walker wrote:
On 31-Mar-06, at 5:25 PM, Nedjo Rogers wrote:
There's an issue on the image module for moving to nodeapi: http://drupal.org/node/43628
Yeah, after looking through the code, I'm inclined to say this makes sense directly in image.module . Do others have a strong opinion?
Good functionality to have. I have written my own module for attaching images to nodes in 4.6.. so that makes about 3 modules doing roughly the same thing. Might as well have it built in :)
"Rowan Kerr" wrote:
James Walker wrote:
On 31-Mar-06, at 5:25 PM, Nedjo Rogers wrote:
There's an issue on the image module for moving to nodeapi: http://drupal.org/node/43628
Yeah, after looking through the code, I'm inclined to say this makes sense directly in image.module . Do others have a strong opinion?
Good functionality to have.
I have written my own module for attaching images to nodes in 4.6.. so that makes about 3 modules doing roughly the same thing. Might as well have it built in :)
Where can one find this module you've written, Rowan? None of the modules I've tried for 4.6 (we're not moving to 4.7) work at all. 'attachment' + 'filemanager' creates files owned by 'apache' and then cause our backup scripts to fail 'upload' doesn't inform you of the path, so you still can not insert an image into the text being edited. I'm (still) looking for a module that will simply: a) let me upload and insert into my content as an '<img>' tag b) let me choose a file that I've already uploaded and insert as '<img>' Who in the world ever heard of "attaching" an image to some content? (Okay, if it's a large graph or chart, then I get the need to have an assortment of attachments to some content, but that's not the most common need, I think.) What are we supposed to use -- that actually works -- to insert images into content!?
On 3-Apr-06, at 12:22 PM, Lists wrote:
I'm (still) looking for a module that will simply:
a) let me upload and insert into my content as an '<img>' tag
b) let me choose a file that I've already uploaded and insert as '<img>'
image + img_assist. Works today, does exactly what you describe.
Who in the world ever heard of "attaching" an image to some content? (Okay, if it's a large graph or chart, then I get the need to have an assortment of attachments to some content, but that's not the most common need, I think.)
Attaching or otherwise associating images with a post make sense in workflows for unsophisticated users (who can't "place" images exactly) as well as set layouts (consider articles with a specific defined region for images). The other thing is that it is only one workflow, whether you are doing images, audio, or videos (or PDFs, or Word docs, or or). This works well in a corporate environment. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
On Apr 3, 2006, at 2:02 PM, Rowan Kerr wrote:
James Walker wrote:
On 31-Mar-06, at 5:25 PM, Nedjo Rogers wrote:
There's an issue on the image module for moving to nodeapi: http://drupal.org/node/43628 Yeah, after looking through the code, I'm inclined to say this makes sense directly in image.module . Do others have a strong opinion?
Good functionality to have.
I have written my own module for attaching images to nodes in 4.6.. so that makes about 3 modules doing roughly the same thing. Might as well have it built in :)
Scary --- I wrote a less elegant version of this over the weekend. Some thoughts skimming the posted code: - my motivation was to replicate "image" type nodes using CCK + an image field managed via nodeapi. In this use, the "caption" is better served by CCK, IMHO. - when you're talking about integrating this with image.module, I'm hoping it'll be in a manner that allows the nodeapi code to be loaded but NOT image.module itself Thanks for the cleaner example :) Roger
participants (14)
-
Boris Mann -
Bèr Kessels -
Darrel O'Pry -
Earl Miles -
James Gilliland -
James Walker -
Jeff Eaton -
Lists -
Moshe Weitzman -
Nedjo Rogers -
Roger Espinosa -
Rowan Kerr -
Sean B. Fuller -
Walt Daniels