Problems still:
1. Those images would only be available through Wicket, as they are components. As they are components, the HTML looks like this:
<img src="/wicket-examples/images?component=1.image2&rendering=0&interface=IResourceListener" id ="image2">
'1.image2' means component with name 'image2' of the page in the session with nbr 1. The 1. changes here. And even if you have similar images, they would be named different ('imageX) as they are separate components.
'rendering=0' also changes ('rendering=n-1') to keep track of stale pages.
2. Even if we built files, and did our trick of converting the references to 'static' url's, we still aren't there yet as we can't assume we are allowed to directly write to our webapp dir (which would make our resources instantly available as a static resource). We can, as Johan and you pointed out, write to a temporary directory. However, putting resources in this directory will not have those resources available to the webserver as static resources. So, in that case we should either do extra administration on the webserver (an that's not an option for a framework like this) or, we should provide a means to access this, like making this a special case and handle it seperately by our Wicket servlet (thus it is not a component).
That could be the starting point I think.
Eelco
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
