[drupal-devel] node-associated image module--advice wanted

[Ber Kessels]

Hi.

> I'm thinking of upgrading my old node_image module and looking for some
> advice.
Great!

> I didn't upgrade node_image for 4.5, mainly because new modules had been
> produced replicating much of the functionality
Please keep considering this, when updating your module. We really do not
need more of the same. Not even when it does that more-of-the-same in a
slightly different way.

IMO we should really get ourselves together and develop *one* *standard*
image to node system.
Why?
* usability: One good working solution, that is maintained over
development cycles will help our consistency and help people getting used
to one system.
* completeness: one full implemented sulution obviously is much better
then three half implemented. Even if 1 < (3 * 0.5).

> but in each case there's
> different logic and user interface.

What path to take: IMO starting with this problem in mind is a very good
start. :)


> The question: which of these approaches is the best model for
> node-associated images?  Which one would be the best to follow in the
> interests of moving toward a uniform approach to image association?

IMO none of them, really. IMO the model does not really matter, as long as
it is used consistent and everywhere!

My idea, is that we have various technologies to achieve the same theing
for an end-user: show an *inline* image on a place in a text.
We, developers, see all sorts of images: nodes, attachements, files,
uploads etc. And thus we tend to treat them different. Wrong, wrong,
wrong! They might *be* differentm, yes, but they should never be treated
that way. The end user should never, ever, have to bother about the
technology behind an image.

so, that all sayd: We need a simple, extendable (is that a word?), and
*global* (as in standard, as in used everywhere) way to add an inline
image to *any* text.
Enter filters: IMO a simple filter token, in the form of [image: XXXXXX]
should do the trick. Then the next step would be to make sure all texts
(comments, nodes, descriptions, biography, blocks, mission, footer,
header, whatevers, etc) are ran trough filters.
How exactly [image: XXXXX] would work does not (yet) really matter IMO.
and what XXXX can, or should be, does not matter either IMO. It could be
the filename, a nodeID, etc. But it should be standard, and easy to
remember and learn (node ids are not easy to remember and not easy to
learn).
And there could be various "command line options"  for that token. (only
described in a help text under "advanced" ). Those options can be stuff
like CSS classes, sizes, alt texts etc. but IMO the defaults should be
automatically created and should be good: A user *may* give a size, but is
never forced to; the default sizes, when not given are good enough.

so, to get back to your question: I do not beleive we need yet another
image to node implementation, but rather an "abstraction layer" that will
be used by users, and by applications like img_assist.

Ber
--