[TYPO3-dev] Bug 1378: hardcoded fileicon path, why is it closed without fixing?

[Franz Koch]

Hi list, hi Michael Stucki,

I didn't know where else to write, since I can't add a comment to a already "closed" bug. It's about this bug: http://bugs.typo3.org/view.php?id=1378.

There has been added a diff which, as far as I can see, does nothing at all, and your comment isn't the overall solution. The iconCObject you mentioned might work for regular filelinks, but:
- you have to apply the cObject in every instance you use (not that nice)
- Extensions might not allow to apply a iconCObject as they might not use cType "filelink" (like most DAM-stuff as far as I see) as it is not flexible enough
- the iconCObject is in my eyes more a workaround then a propper solution and needs enhanced TS knowledge
- a simple check for a path-variable is much faster then processing a in most cases oversized iconCObject

Why is it not possible to provide a global configuration variable in typo3 that the core and any extension can rely on? I have no clue of the core itself (not in total), but I really can't imagine that it is that difficult to add a new property to TSconfig -> page.config and check against it. And a check might not even be needed, as the currently hardcoded path could be the default setting for this parameter.

Wasn't typo3 4.x about usability also for developers? Making things more complicated then necessary, only because the functionality is already there, isn't the right way. Who actually uses the iconCObject to simply change the iconPath (without any further processing of preview-images etc.) and doesn't think this is oversized?

Just my two cents.

-- 
Kind regards,
Franz Koch