In some ways this is a follow-on to mega-thread here - http://drupal.org/node/208136 and a result of sun's request here http://groups.drupal.org/node/13898#comment-50018 (more thorough comparison/overview in the works)

One of the ways Asset handles images is via inline text tagging similar to Inline and Image Assist, but as with these, it only does so for those files uploaded as Assets via its own browser UI. IMO Ideally one module would handle the display of such tags and allow them to reference any files in the filesystem, no matter what module "owns" that file.

But that's not what this post is about :)

The other way Asset handles images is by enabling a CCK field of type Asset to reference an image, again files uploaded as Assets via its own browser UI. The big advantages IMO over Imagefield are:

  • since the file reference itself is in the Asset table separately from the node reference, these files can be stored in multiple CCK fields and multiple nodes.
  • Asset lets you specify when uploading your target directory, creating them on the fly if needed, or batch uploading as well. This is what lets you have some organization system rather than dumping them all in one place, since the images aren't stored as nodes and therefore can't be referenced by taxonomy terms.

So now we're getting to it - it should be relatively easy for Wim to do much of what I'm looking for here (says the non-coder :) http://drupal.org/node/319370

but he shouldn't have to write an image browser that uses taxonomy to find Image module files.

If Image Assist could "plug in" to Asset to be used as that browser, and this then allows Image module files to be embedded in CCK fields without having to re-upload the files, then I think we'd be a big step forward in rationalizing image handling in Drupal.

Thanks for considering these ideas.

Comments

HansBKK’s picture

HansBKK commented

also posted to Wim's Image group's thread on Asset

http://groups.drupal.org/node/13898#comment-53444

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Postponed (maintainer needs more info)

I'm not sure I completely grasp what you are talking about here. As mentioned in the other issue, Image Assist follows the paradigm that Drupal should handle and manage files as proper system objects, so they can be created, edited, tracked with revisions, categorized, tagged, rated, listed, referenced, published, unpublished, *accessed* by certain users/roles only, re-used by other modules, resized on-the-fly, imported, exported, *described*, geo-location-enhanced, enhanced with EXIF data, enhanced with custom fields via CCK, shown in a "Latest image(s)" block, integrated into any Panels/Views, etc. pp

So, to make this clear, I am a strong opponent to any module/system that allows users direct file access to the file system and thereby bypasses all Drupal APIs. This is what modules like IMCE or Asset do, AFAIK. I will certainly not waste my time for integrating them. But then again, I'm not completely sure whether this is your intention. ;)

HansBKK’s picture

HansBKK commented

Sorry I wasn't more clear - yes, I was hoping Image Assist could be enhanced to act as Asset's browser for files referenced in Image nodes, both for CCK fields and inline filter tagging. Thank you for the clarity of your response.

FYI Asset registers the path to its files in the files table and then references them via fid. IMHO this is a good compromise between full node status and the "just point directly to the file" behaviour of some image-handling methods (not only IMCE but AFAIK all RTEs?).

Regarding your "all files should be nodes" statement, are you saying you're in general opposed to any departure from this, or just in relation to your extending Image Assist?

To paraphrase a past comment by Dries (couldn't find the exact reference, but along these lines)

> I disagree with this. If a file is "just a file" and doesn't need the things that being tracked as a full node brings, then forcing it to be a node doesn't add value, just clutter and administrative overhead.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

I don't know enough about the inner workings of Asset to tell whether Image Assist's browser and inline macro processing (which is handled by Inline API soon) could be integrated with Asset in any way. Maybe the new Views-based browser in 2.x will be a step towards this.

Regarding Asset using the files table and Dries' statement: It might be worthwhile to point out that Image Assist directly used the files table a few years ago. You still find some legacy code in the module, which is just there to support old, obsolete img_assist inline tags (which cannot be mass updated easily). So, from a historical view, Image Assist has matured, and has overcome the limitations that a simple file based storage and access system implicates. The reasoning is already covered in #2.

Starting with D7, however, we might be able to rethink the overall concept, since files are first class objects like nodes and users in the next release of Drupal core.

HansBKK’s picture

HansBKK commented

Yes, I saw some talk about the new directions for D7's File API, I guess something in between full file-as-node and just a record in files table?

>You still find some legacy code in the module, which is just there to support old, obsolete img_assist inline tags (which cannot be mass updated easily).

Does this mean there is a syntax for Inline to reference entries in the files table by fid, so that it can render images not directly attached to the displaying node?

If so that would be exactly what I'm looking for, would save me a lot of redundant uploads, so would be worth manually looking up the fid, typing the tags etc.

I realize this isn't your intention with the module, but if the code is there to support legacy usages anyway I would like to be able to take advantage of it, but I doubt I'd be able to decipher source code.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Well, after a recent review, we discovered that the legacy code, which provides support for this, contains major bugs and should not even work at all. However, there were no complaints or any issues from users about it since I became the maintainer. Hence, this legacy code is about to be dropped before 2.0 will be released.

I still do not understand why you are still ignoring the benefits of images as nodes. ...would save me a lot of redundant uploads, so would be worth manually looking up the fid, typing the tags... suggests that you are even speaking of a small Drupal site, where a few additional nodes are not worth the whole discussion at all.
If you had said that you need a way to handle 10.000.000 of files, next to a comparable amount of nodes, and maybe users, and all of the files should be re-usable, this discussion might make more sense - but even then, you would probably want proper access permissions, taxonomy, file metadata, and perhaps additional rating features for files to allow your users to find a particular file more easily.

HansBKK’s picture

HansBKK commented

OK, thanks Sun, historically interesting but not a valid track to investigate further.

And thanks for helping me put things in perspective regarding the performance/clutter issue, and of course you're right, for this particular project, at this point in time, it may well be perfectly appropriate to have ALL the site's images stored as nodes - even the purely decorative ones referenced only by the theming layers?

However Imagefield/Filefield-based image handling has a lot of momentum in the community, and many well-respected people are depreciating further use of Image module, if not actually suggesting it be deprecated. After investigation, I see some of the advantages and disadvantages of that approach, and ultimately I'm trying to come up with a way to handle images, so that I have maximum flexibility to handle needs I don't yet know my site has, as well as insurance against having to re-edit node content as I upgrade the site to future versions of Drupal.

Moreover, my point of view is not just this current project, nor this current point in time in Drupal's evolution, nor even just my own needs as a developer. I'm trying to take advantage of my current relative newbie-user POV to make suggestions that may help move the community move forward by pointing out the relative advantages and disadvantages of the different module's methods and suggesting ways to work toward having "one best way", ideally eventually in core, or in the meantime working toward better interoperability between the different approaches.

I am also trying to help clarify things for others even more ignorant than myself.

Thanks for your help and advice Daniel, and most of all for your patience with me.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Of course, images belonging to a theme should be placed in the theme and not into contents, resp. the database. Otherwise, Drupal's theme system would be invalidated and you could not easily switch to a different/new theme.

I know that most other CMSes like Joomla & Co. (only) provide image management via direct access to the filesystem. It is a simple way to allow users to use and re-use images in their contents. However, they all lack the benefits and features mentioned in #2, so you (as an site administrator) have to grant all or nothing, and of course, you only have folders (if at all) to organize and "describe" your images. For example, you have to re-type the alt and title attribute for images all over again, each time you insert an image, because the system knows nothing about the image at all.

Trust me, when I was new to Drupal and first was faced with Drupal's image handling, I had similar doubts like you. I tested and implemented most of the other modules that existed back in those times just to find out that my accustomed approach to image/file handling was too limited in terms of Drupal's capabilities.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

All points noted and the evolution/time will tell.