[TYPO3-hci] files_with_pages backend extension

[JoH]

I didn't copy the original post since I don't give a real answer to it but
try to explain why the current way of handling files - and especially image
files - is giving us a better usability than the "files_with_pages"
solution.

I don't know if you have ever worked in a real press center or as an editor
for a bigger newspaper or similar publishing company.

Usually they work together with lots of photographers selling them thousands
of images each year. In addition they are buying stock images from different
resellers. All those images are stored and categorised in a big archive that
any editor can access if he is in need for some special images for an
article or a press release.

The categories are based on different aspects like content, colors, mood or
dimensions but they never reflect the current page tree of the magazine
those people are working on, simply because it wouldn't have much sense,
since the next time they would need a similar image the context might be
completely different and they would never find it if they had to search for
it in the page tree of the january edition.

Producing a huge website with thousands of images basically works with the
same principles. You will have photographers and editors working on smaller
parts of the whole site and they all will access this huge archive which is
called the "fileadmin" if you are working with TYPO3 or maybe the DAM
folders, if you are working with a modern version of the framework.

Reflecting the page tree as a whole in that archive IMHO is no good idea,
since you would have to change the structure of that archive each time the
structure of the site changes.

Usually the editors are going to the archive, select the images they need
and then make copies of these images that are stored in the page or a
content element (which means the uploads or media folders from a more
technical point of view), while the originals are still available in the
archive where they can easily be found by other editors  with completely
different tasks.

It could be a good idea to offer those editors an additional filemount where
they can put copies of the images they want to work with, but even inside
this filemount I don't see a reason why it should reflect an exact copy of
the page tree.

If you got problems in this case, I think the lack of usability lies in your
concept of handling files with the fileadmin/DAM but not in the basic
principle of separation between the "archive" and the "workspace".

But there is one idea of your posting that could be very useful while still
working with a separate archive: The images that are related to a page (be
it in the page record itself or any content element/plugin it contains)
could be listed in a "show related images" view, to give the editors a quick
overview and make it easier to add, remove or replace them without having to
enter each item separately. This is something that can be provided by the
DAM extension (or some of the DAM extending extensions) to avoid the waste
of harddisk space that is created by the real copies of the images in
uploads or media.
The principle would still be the same, but the copy wouldn't be a real copy
anymore but a virtual one and the overview would be much more usable than
the current way of handling images and files.

What I still can't see is a reason for your "1:1 copy of the page tree"
approach.

BTW: Most of the stuff I described is already possible with DAM
You should give it a try.

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your knob sometimes!)
Dieter Nuhr, German comedian
openBC: http://www.cybercraft.de
T3 cookbook: http://www.typo3experts.com