[TYPO3-core] RFC #14785: add feature: Add HOOKS to class.t3lib_iconworks.php for developing alternative backend-skins!

[Stephan N Kellermayr]

dear Jigal (and other TYPO3-(core-)developers),

it is correct, my description was not very precise, but it is hard to 
explain without an example.
i agree, XCLASSing is not very good, and HOOKS are bad too... so i wrote 
this extension to show you how i would solve the icon-thing.
to give you the possibility to understand what i meant with "missing 
feature", please give this example a try.

http://www.t3x.at/downloads/T3X_t3xskinexample-1_0_0.t3x
(activate t3skin before using this example)

it is a small extension, which does not replace anything, it just 
provides the following things:

1. a modified version of 'class.t3lib_iconworks.php' for better 
classname- and iconname-generation (!important).

2. replacements for the images 't3-icon-apps-pagetree.png', 
't3-icon-mimetypes.png', 't3-icon-status.png'

3. replacements for the css-files 't3-icon-apps-pagetree.css', 
't3-icon-mimetypes.css', 't3-icon-status.css'
(the images and css-files are in the folder of this extension and are 
activated with 
$TBE_STYLES['skins']['t3skin']['stylesheetDirectories']['sprites'])

4. ...and some additional informations in the TCA-array for some 
system-tables.
(take a look at the added arrays 'typeicon_disableDefaultOverlay' and 
'typeicon_classesAlternatives'!)


note: this example ONLY focuses onto pages and some mimetypes to show 
the concept!!! some icons (status, overlays, etc) and pages which 
contains modules are not processed in this example.



the things i modified in class.t3lib_iconworks.php are:
1. added a function which processes starttime/endtime and returns a 
meaningful string.
this is done to show a preciser baseicon/overlay which allows to 
visualize the hidden-state caused by timing-options.

2. modified function 'getIcon' to add the option 'nav_hide' to older 
systems which uses 't3xskin'.

3. modified function 'mapRecordTypeToSpriteIconClass' to get CSS-classes 
for a spritematrix (base-icon-alternatives).

4. modified function 'mapRecordOverlayToSpriteIconName' to get more 
possibilities with overlays.
sorry, the currently used concept with 
'spriteIconRecordOverlayPriorities' is complete nonsense, because you 
lose important information!
...so i used a concept which simple concatenate keywords.



the following things are very strange in t3skin regarding pages, so i 
removed them in my extension:
1. CSS-classname 't3-icon-pagetree-page-mauntpoint' does not make any 
sense, its just a typo, remove it!

2. CSS-classname 't3-icon-pagetree-page-not-in-menu' is deprecated.
(mimetypes-x-content-splash is also deprecated and it neither exists)

3. CSS-classname 't3-icon-pagetree-page-no-icon-found' does not make any 
sense, because it should never occur!
(...or would you drive a car with a missing wheel?)

4. the CSS-classname for the spacer should be named 
't3-icon-pagetree-page-spacer' instead of 't3-icon-pagetree-spacer' 
because it is a page!

5. the same as above with CSS-classname for the folder: 
't3-icon-pagetree-page-folder' instead of 't3-icon-pagetree-folder'.



i hope i can inspire someone with this exmaple and reveal the 
icon-mystery which i was talking about.

however, if this couldnt make it into source someday, i will just 
provide an (manual) override of 'class.t3lib_iconworks.php' for upcoming 
versions of 't3xskin'. there are many people who will take this little 
obstacle to get a better looking TYPO3-backend.
no harm meant.


best regards, Stephan


Jigal van Hemert schrieb:
> Stephan N Kellermayr wrote:
>> type: feature
> 
> Features should wait until 4.4 is out, so they might get into 4.5...
> 
>> problem:
>> at the moment there is no possibility to extend the class 
>> 't3lib_iconworks', which is very bad for redesigning the backend, 
>> because you stuck on the implemented functions which handles the 
>> sprites and icons.
> 
> I still agree with the replies to #14711; if there is improvement for 
> the current functions this can go into a patch for iconWorks. If those 
> improvements are not accepted a hook request may be a possibility to get 
> your functionality working.
> 
> Hooks take resources each time the code is executed, so they should be 
> added with care.
> Your description is too vague for me personally; it's not a real use case.
> 
> I agree that there is room for improvement for the sprite functionality, 
> but the goal was to reduce the number of requests to the server for the 
> backend and that was achieved with the current implementation.
> 
> Let's see what the core devs say about this patch...
>