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

[Franz Koch]

Hi Mathias,

>> 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?
> 
> I do.
> Basically I get your point.
> But what we do now is the following:
> There IS a functionality, that does what you need (flexible, so you call 
> it oversized).

Yes, it works and the functionality itself is a good thing for manipulating icon-rendering etc., but it is way to complex to simply change a path. Like it is possible to define a alternative fileadmin path that can be globally checked, this should also be available for the icons, flags etc. so that extension developers also can rely on that value in their extensions to finally get some consistency for the filelisting and DAM extensions. I don't get the point why there has to be processed a huge rat tail (german: Rattenschwanz) of code named cObject with lot's of stdWrap-stuff to simply change one string? Isn't typo3 already slow enough?

> If we now add the diff there are suddenly TWO ways of doing things and 
> while you might be satisfied with the solution other people will come up 
> with the point "why are there two ways of doing the same thing? I am 
> confused, I hate TYPO3 and all of you" (little overrated, but you get 
> the point ;-))

Isn't it the typo3 way that there are always multiple ways for doing things? The backend is full of it ;)

-- 
Kind regards,
Franz Koch