On Wed, 05 Jan 2005 00:20:52 +0100, Eelco Hillenius wrote:
>But... this is not the drastic gain. *The* drastic gain is - like
>Johan's example - to let the browser know the image/ resource can be
>cached. You do that by tweaking 'getLastModified' and setting cache
>control headers. However, that will only work for requests that look the
>same (have the same URL). Our's don't, because we have that render count
>parameter (amongst others). So we should somehow be able to convert the
>resource url's to 'static' ones. Dunno how (yet).
Fine, but I think we can solve both client-side and server-side
caching issues with one swoop. You're asking how we can somehow convert
our resource URLs to static ones and I repeatedly suggested having a
lookup table that resolves input parameters to output filename. Maybe
that is too inflexible.
You know what? I've got a good idea..... Currently you use
class DynamicImage for generating images. Why not use
DynamicImage.hashCode() for building the filename? Specifically,
DynamicImages with the same hashcode are said to contain the same image
and the static URL would contain <some prefix>+<hashcode>.<extension>.
The developer would be responsible for overriding hashCode() anytime he
overrides the getImage() (say he wants to render the image differently
on every page refresh). Our default hashCode() would have to return a
value based upon getImage()'s contents.
What do you think?
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
