[development] Re: image node type

[Ken Rickard]

>> So, yes, we definately need to keep the option to let people place media
anywhere. And yes, that needs to hook into WYSIWYWFU interfaces. But, no,
this is not as badly needed as Simple Inline Media Handling. We need both,
we need the flexibility, but IMHO an automatic-no-clutter solution should be
the default. In core.

I'm with Ber most of the way here, having struggled with some heavy image
requests in a rather rigid templating evironment before.

First, some discussion thread voting!

+1 for files as an abstract data type full of rich, creamy metadata.
+1 for image nodes (as a content type that exploits file uploads).
+1 for browsing/creating images while creating other nodes.
+1 for attaching files to user profiles.
+1 for upload once, use many times.
-1 for inline tokens [that's why we have HTML/PHP in posts!]
-1 for requiring theme editing to handle file/image presentation.

Here's what I'd recommend (humbly) for Drupal.

Do not rely on theming to handle variation of presentation -- if advanced
users want to do theme backflips, let them, but "normals" need nice file
handling too.

The default presentation of media that are attached /associated with nodes
should be handled via /admin as part of content configuration.  Some needs
from an admin perspective:

1) Some node types might not accept any media attachments.  Some might
accept all.  Admins should be able to decide based on what files users can
upload.

2) Placement of attachments (by type) with relation to the body of the node
should be set muich like custom blocks are set now.

3) I would even propose that attachments hook into the new (4.7) region
system rather than the standard content system. (I'm writing a custom block
right now that does this by reading the file extension of objects added to a
given node via the attachment module.)

4) If attachments are not treated as blocks, placement of attachments within
the body of the content might be done like teasers are defined now (insert
photo 1 at character 400; photo 2 at character 1200; insert PDFs at node
end; etc.).  (This is the code I had to write in the other system).

4a) Be prepared to handle multiple objects of the same data type.  There may
be, say three ways to handle groups of photos.  Option 1: Load one photo and
link to the group as a separate node; Option 2: Load all in a region of the
page; Option 3: Use AJAX or similar code to dynamically rotate pix on
command.

5) Access control for attachments would define which roles could override
the default placement of attachments using a token syntax (which, on general
principle, I oppose, but will agree to include if others like it).

The bottom line is this: a system like teasers, where the site admin sets
the defaults, with an allowed override for advanced users.

And while I would agree that WYSIWYG is not necessary, point-and-click setup
by admins (rather than theme editing) is.

(And, for the record, my clients all want to be able to layout their pages
with photo 1 at graph 1, align right; photo 2 at graph 6 align, left; with a
big fat ad space between graphs 3 and 4,)

--
Ken Rickard
agentken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20051211/a1403409/attachment.htm