[TYPO3-dev] Suggestions for triggering BE sprite generation

Dmitry Dulepov dmitry.dulepov+t3ml at gmail.com
Fri Jan 29 14:14:55 CET 2010


Hi!

I already commented once but I would like to ask deeper questions.

On 2010-01-29 11:52:59 +0200, Steffen Gebert said:
> How would you implement a sprite generator?

This is a wrong question to start with. This question misses a goal 
completely. According to the question the goal is "implement sprite 
generator". I do not think it is right. Why do we need sprites? To 
speed up web site loading. This is a goal. How does sprite ~generation~ 
feet to this goal. It doesn't.

> Most important thing is: When will the sprites be generated - or should 
> they be generated at all?
> 
> Ideas:
> 
> dynamic
> =======
> - 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)
> - 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

This is a process. Now you will get technical issues. Have a look to 
your install tool where image checks happen. Do you see that images 
generated correctly there? I don't. I have three separate machines 
under hand and none of them generates images properly in the Install 
tool. All three machines use the same command and all three results 
look different. Are you sure you can make sprite generation identical 
for all ImageMagick versions out there and all GD versions? Who will 
fix bugs when sprites are generated incorrectly? Will you? :)

> static
> ======
> - 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

This is easy. We prepare sprites in photoshop. Here is my example of a sprite:
http://www.calis.lv/aprunasimies/forums/templates/images/message-bar.gif

This site where I use sprites is very high traffic site (millions of 
hits daily). The bar is static but HTML shows various icons for 
different users (admins, moderators, registered or unregistered). But 
sprite is static and highly optimized in Photoshop. It has long 
expiration time because it does not change.

> - long browser cache life-times? how can we trigger reload of the file?

This is easy. I use it on the same site but for JS and CSS. My CSS and 
JS file names look like "styles.20100129.css" and there is a rewrite 
rule that maps it back to "styles.css". So if I ever change styles.css, 
I change date in HTML. All clients fetch a "new" file, which is 
client–cached again. This works already for years and it ptoved to be 
very effective.

I like simplicity. I do not like unnecessary complexity, especialy if 
it is made because it is technically cool. Sprites generation is 
technically cool but it is worhtless in terms of having a real goal 
behind it. Therefore I strongly against it.

-- 
Dmitry Dulepov
TYPO3 expert / TYPO3 core team member / TYPO3 security team member 
Read more @ http://dmitry-dulepov.com/





More information about the TYPO3-dev mailing list