[TYPO3-dam] DAM - reflection on "kill mod_file"

georg k georg at georg.org
Sun Apr 15 20:51:47 CEST 2007


Rene,

I might have better said:
Let's combine the function of mod_list and mod_file into ONE module.

My main point is that the editor should have one module available, which 
allows the handling of all functions he needs, and only the ones he 
needs (config via. InclAccessLists, GroupTS, PageTS).

René Fritz wrote:
> Hi Georg
> Thanks for your analysis. I would like to hear other opinions but I just want 
> to add some notes for now:
> 
> - When building a DAM from scratch the fileysystem might not have been used at 
> all. But it's build to work with TYPO3.
clear;

> - The Media>File>List module can be disabled
ACK, however mod_file does not offer the language functions mod_list 
does (Language / exclusive), and mod_list not offer for uploads / 
directoty handling, so currently the Editor has to use both modules for 
the simple task of: upload a file, add Metainfo and translate Metainfo. 
(or am I missing something?).

> - Administrators might need a Media>File>List module
For sure they do. - see above: combination might be a solution.

> - Media>File>List and Media>List>List shares much code so it's not that much 
> work to maintain them. And they are already there :-)
ACK;

> - There's a scheme needed how to store files when the usage of folders is 
> dropped (in the interface). Means, where to store an uploaded file when the 
> folders are hidden for the editor?
I cant imagine a setup with completely dropped view on the file-system 
(be it a real-(FS) or virtual hirachy).
Why? The avverage editor is used to the concept of a hirachical 
structure and will want to use such in order to strcuture his data.
-
In any way, in case it has to be removed for whatever reason, uploaded 
files might be stored in a temp-upload location and depending on 
auto-indexing rules and/or the user-added-meta-information and 
categories the file might be moved into the appropriate location.

regards georg

> René
> 
>> - mod_file "feels" a bit orphaned (code + function-wise).
>> - mod_file is missing quite some very important functions mod_list
>> offers. (Languages, Translation, Versioning ...)
>> - mod_file's extensive calls to the FS for information that's already
>> available in the DB are lame.
>> - It makes no sense to force the Editor to switch between mod_file and
>> mod_list in order to complete the most standard tasks at hand, which in
>> the most cases is pretty simple:
>>      - upload + add meta-data
>>      - modify or translate meta-data
>> - maintaining mod_file + mod_list at the same time seems to be
>> ridiciuolus. (Rene & Developers workload-wise).
>>
>> WHY-NOT:
>> - mod_file offers create-folder- & create file-functions (which the
>> avverage editor should not really need).
>> - mod_file optionally provides filesystem-information (RW), which
>> basically is useless to the avverage editor.
>> - Simply enabling mod_file for the avverage editor seems to be the best
>> option when migrating from classic typo3-file-handling;
>>
>>
>> HOW:
>> - MUST: Add the File-Uploads-Function / Tab / to mod_list.
>> - MUST: Add some config-options (blind functionality) to mod_list so
>> that it looks / acts like the current mod_file "view" for editors, which
>> is IMHO the most usable dam-interface for the avverage editor.
>> - OPTION: Add create-folder- / create file-functions to mod_list.
>> - OPTION: Add the R/W - File-System-Information as an (admin-) option to
>> mod_list in case needed at all.
>>
>> MY PERSONAL ESSENCE:
>> - Media>File feels a bit outdated, however it's currently the "best"
>> Interface for "normal" Editors, as for it's clean and usable interface,
>> providing an optimal ammount of information, options & functions.
>> (actually only uploads, translations + versioning are missing).
>> - In other words I feel that, Media>File could be removed completly
>> (depricated) in favour of a Media>List Module with the above mentioned
>> changes.
>> - Putting it the other way around, would mean to add language &
>> versioning capabilities to mod_file and mantaining it as a separate
>> instance. I feel that this makes even less sense.
>>
>> Your thoughts?
>> Would you miss mod_file in case the above "HOW"-s are given for mod_list?
>>
>> regards georg
>> _______________________________________________
>> TYPO3-project-dam mailing list
>> TYPO3-project-dam at lists.netfielders.de
>> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-project-dam
> 
> 
> 


More information about the TYPO3-project-dam mailing list