Ok, things are beginning to make more sense now. So we have a
table with ten rows and each row contains a reference to the same
packaged image and you're saying it isn't being cached. Is this because
the URL is different or our headers are incorrect? If the URL is
different, why is that so? I mean, I am expecting each row is a
different instance of the same class. Are you saying that the object ID
is somehow codified into the image URL?
Again, wouldn't it be ideal if we could somehow map
BufferedImage -> hashCode() and apply it universally across all of
Wicket for packaged static imaged and dynamic images? This way if the
user uses 1000 different copies of the same image across different
directories or components, they will *still* all resolve to the same
URL and get cached properly. Just food for thought...
The downside there is that if all images resolve to the same
URL (because we know the images are identical) then you lose the
ability to set different cache settings per image. But then, what you
are currently suggesting is the same thing. Who is to say that in the
future users might not want to set different expiration headers for the
image on some rows but not others?
Gili
On Wed, 05 Jan 2005 00:33:55 +0100, Eelco Hillenius wrote:
>I think we do have a little misunderstanding here ;)
>
>All the time I was talking about packaged (e.g. in a jar file), static
>resources. Dynamically created images are a whole different thing; I
>guess these could be either kept in memory or - if you want to keep mem
>consumption within limits - generate them to temporary files.
>
>My whole point so far is that the way Wicket handles things (everything
>is a component) works great, but has a negative side effect in that
>packaged static resources (ie images and stuff that you keep in java
>packages) are bad for performance.
>
>As an example, if you have a ListView, that you populate with an image,
>and you have ten rows in the list, you'll end up with eleven servlet
>invokes; one for the page, and one for each image (ten that is), as
>those images, even if they are exactely the same images, will be
>seperate components, that are thus requested seperately. Ideally, you
>want just one request for that image, and have the browser know, he
>doesn't need the others because that image is allready in it's cache.
>
>Also, on a next request (e.g. a click on some other component on that
>page, will result in again ten requests for the images, as the browser
>still regards those images as non-cachable.
>
>Eelco
>
>> Ok, I follow you so far, so why does this prevent us from
>>serving up dynamically generated images from tempdir? I'm guessing
>>you're only objecting to the idea of serving up static images using the
>>servlet as opposed to using the webserver? I'd just like the ability to
>>dump my static images into the WebApp directory. It would be an option,
>>nothing else. There is nothing preventing us from dumping the static
>>images into another directory that the webserver can get at directly,
>>right?
>>
>>Gili
>>
>>
>>
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by: Beat the post-holiday blues
>Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>_______________________________________________
>Wicket-develop mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
