[TYPO3-v4] spriteGeneratorApi / Api to make Icons usable for SpriteApi

[Steffen Ritter]

Hey list,

sprite-icon-api is now included in beta2.
Sprite-Icon-Api is only a litte piece of a puzzle:
In short the task of this api ist to "replace" t3lib_iconWorks::skinImg 
for showing Icons in the backend.
As sprite api works with css classes beside of image-Tags (as skinImg) 
this will fail as long the icon is not included in the backendstylesheet.

When will this happen: easiest example: the record icons of extension 
tables. List-Module would build them via spriteApi, but core-stylesheets 
cannot have css definitions for extension icons.

Therefore, there has to be another API which handles to Icons in TYPO3.

In the current sprite-icon-api I solved the problem with an temporary 
helper function buildTcaSpriteIcons, which builds an stylesheet-file for 
all tca-table-record icons and registers them as "usuable" in the 
sprite-icon-api. There, noe sprite is generated but every icon is loaded 
as single...

In long term there has to be concept / handler to make this transparent 
and which might be able to auto generate sprite-files and additionally 
allows extension developers to register icons for use in the icon-api, 
so that, their be modules might be skinned to.

Since there has been a very long discussion about "should we generate 
sprites", "should they be static", "sprites at all", "how many sprites 
should one have" etc. this concept has to be very flexible.

So we thought about an concept, which could be implemented fast enough 
for 4.4, would allow enough flexibility to fullfill all wishes arised in 
the discussions.

What do we know so far:
-----------------------
  - We do have a sprite icon api, which tries to mark all not "present" 
icons with a red qustionmark.
  - currently the list of "available icons" is hardcoded
  - wie do need an "IconManager" which handles that, build stylessheets 
and sprites if needed or wanted.
  - the current "workaround for tca-icons" checks every "call" if the 
stylesheets should be rebuild


What I have done:
--------------------
  - invented t3lib_iconManager, who should take care of the things 
mentioned above
  - invented an interface t3lib_iconManager_spriteIconGenerator
  - made the handler configurable: 
$GLOBALS['TYPO3_CONF_VARS']['BE']['spriteIconGenerator_handler'] 
(objects which implement the above interface)
  - writeCacheFiles (which writes temp* in typo3conf) calls 
t3lib_iconManager::rebuildCache(), which initializes the handler to take 
care.
  - t3lib_iconManger contains two static function for extension Developers:
    t3lib_iconManager::addSingleIcons
will allow Ext-Developers to register their icons to get included in 
sprites, which they may use them afterwards with 
t3lib_iconWorks::getSpriteIcon('extensions-$extKey-iconName');

    t3lib_iconManager::addIconSprite
      if the extension ships an already build sprite with corresponding 
css, it can be registered with this function


The plan is the following:

typo3 4.4 should ship an "simple" handler (becuase of the timeframe):
t3lib_iconManager_simple implements t3lib_iconManager_spriteIconGenerator
This one just does, what our workaround 
t3lib_iconWorks::buildTcaSpriteIcons already does, plus the icons 
registered via the api. But without sprite-generation. All icons are 
just included as single background-image.

This will make the sprite-icon-api just committed usuable for the core 
as of now. There is only a performance gain in core sprites or static 
sprites delivered by extensions.

TYPO3 4.5 should ship t3lib_iconManager_autoGenerateSprite and 
t3lib_iconManager_manualGenerateSprite

The first should generate sprites from all registered single icons on 
demand if needed.
The second one just should handle registration and stylesheet-inclusion, 
the sprites would be generatable on "click" in the backend.

Via Install-Tool everybody could configure the iconmanager to behave as 
he wants to, via just adjusting the handler. Additionally everybody 
could implement his own sprite handler, if the shipped one does not fit 
the needs.

I attached the proof of concept ZIP which implements 95% of what would 
be needed to implement this concept for 4.4. With it, the 
sprite-icon-api could be used in 4.4 backend.
Naming, CGL, comments for shure I did not look at, since it is "more a 
proof of concept". If you like it, I will overwork it (with Benny and 
other interested) until Beta3. The longest part in the attached files is 
a plain copy of t3lib_iconWorks::buildTcaSpriteIcons.

I'm looking forward for your comments.
I hope my last 4 hours working on this concept have not been superfluous...

regards

Steffen