[TYPO3-dev] Suggestions for triggering BE sprite generation

[Ernesto Baschny [cron IT]]

Steffen Gebert schrieb am 29.01.2010 10:52:

> as some other threads got a little OT, I'd just like to start this one.

Thanks!

> How would you implement a sprite generator?
> 
> Most important thing is: When will the sprites be generated - or should
> they be generated at all?
> 
> Ideas:
> 
> dynamic
> =======

I like this one.

> - creating sprites at the first request, saving them to typo3temp/
> - hasing the array of included images (only filenames) to get the cache
> filename
>   -> icon changes would require clearing of typo3temp/
> - more sophicistic cache calculation: last modified date + file size
>   -> overhead for each single request
> - saving the generated filename in cache, clearing this entry after
> clearing config cache (or a new BE cache)

A hash of included filenames (and maybe mtime of those files) would be
good, allowing the browsers to cache the generated files forever.
Because if something changes in the icons, there will be a new file with
a new name. Storing the filename in the same "cache" as the file itself

> - the selected skin has to be incorporated - we shouldn't obstruct the
> way to per-user skins, also multiple simultaneous skins should be
> possible (e.g. one skin which only styles the page tree etc.)
>   -> one file per skin? generating *one* user-specific file, based on
> his skin selection and merging all together

Yes, one file per skin sounds nice.  Something like
typo3temp/images/retro_skin/sprite<hash>.png
typo3temp/images/retro_skin/sprite<hash>.css

The filenames doesn't even have to be stored in the database, we just
need to include the "*.css" file that is there.

> static
> ======

It might be easier to do (no further programming required), but we get
very unflexible when it comes to changes. I like the "magic" of the
dynamic way.

> - core brings a static sprite for t3skin (do we use an online generator?
> do we use a PSD? BE module to generate them?)
> - extensions also bring their own (don't know, if this really needed -
> are there SO many icons?)
> - extdeveval or similar to create sprite+css for extensions
> - NOT saved to typo3temp
> - long browser cache life-times? how can we trigger reload of the file?


> Further thinking:
> - currently all icons only 16x16
> - skin with bigger icon sizes?
> - does extensions have to ship multiple sizes?
> - *should* they be able to ship one bigger icon (64x64?), which is scaled?

Good questions. One of the main advantages of a "skin" is that another
look can be generated, which includes the ability to provide "larger
icons". But of course this means all extensions must provide the larger
icons, which won't be possible (or even desired by the extension authors).

So I think that if someone wants to create a "larger-icon-skin", it
should be possible, but the skin author has to have a possibility to
overwrite / provide proper extension icon replacements. If none is
provided and we only have a 16x16 icon, it should be padded in with
transparent color to reach the bigger size.

skin with 20x20 icons:
- skin provides all core 20x20 icons
- skin provides some "major" extensions 20x20 icons
- core generates missing icons from the 16x16 variants with 4 of
transparent padding around the icons.
- extensions which provide >20x>20 icons (e.g. 64x64) gets this variants
scaled down to 20x20

So the extension author could just ship 64x64 icons and it should work
with every skin with less pxs. If she wants specific-sized icons (e.g.
core compatible 16x16), she can also ship those along.

Cheers,
Ernesto