Juergen Donnerstag wrote:
I haven't found the time to actually run it. But, I use css images with the nested tree variant. The flat tree variant however does use 'real' images. Currently I just a an HTML container for this (and then use <img) and use a ComponentTagAttributeModifier (fweh.. what long is this name) to modify the src attribute. In the latter case, using image components would be disasterous for performance.Eelco,
not sure my informations will really matter (could be I lost track of the mails)
1) you remember the appfuse resources I send you? The menu component
is a kind of tree and the images are defined in the css file and url
refers to a static resource outside my wicket. I've checked it with
HTTPLook, an http traffic analyser, and the client retrieves the
images only once.
Furthermore, you'd generally want to prevent browser caching for Wicket requests, as these are dynamic. As requests for Wicket resources like images are full Wicket requests, handled by a servlet etc, they are probably marked as not cacheable. And then there is that render count parameter, which has the effect that the image's URL is different on each request.
2) wicket is using sourcepath and classpath iin that order to locate
resources. assuming images are not in classpath and sourcepath is set
to myApp-Home, wouldn't it be possible to create kind of "standard"
(static) urls without wicket specific query string to point to these
images?
Still, the problem would be that these requests would come in via Wicket, instead of doing a request that the server regconizes as being e.g. an image. For such an image, there is no overhead of executing a Java servlet, and servers can be optimized for handling such images (e.g. by using apache to server the non-servlet part).
The problem with unpacking resources into the webapp dir (because that would work) is that it is too dangerous to assume that your webapp has write access. This is especially true when working with containers like JBoss etc.
One possible way to increase the cacheability is to use HTTP cache headers to encourage browser caching in some cases. This could only work if we could loose the render count parameter somehow. And as caching could never be the general rule (e.g. not for dynamically generated images), if we decided to follow this path, it should be configurable per resource.
Eelco
Juergen
On Sun, 02 Jan 2005 02:49:01 +0100, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
Sure, not that important right know. Good to be aware of though. We should file it as a feature request for 1.1 IMO.
Eelco
Jonathan Locke wrote:
sounds ugly. i bet we want to fix this. 1.0 or 1.1 though? i just want to get everything wrapped up. wicket will /work/ without this perf tweak. delay?
Eelco Hillenius wrote:
With the risk of starting another thread... though it is very nice to have these kind of resources, they are also quite inefficient to use. In the case of images: as the image url's constantly change (via the rendering count), the browser will never be able to mark them as cached.
It would be neat to have some kind of caching option for these kind of resources. The perfect solution would be to unpack the resources on startup to a directory that is available to the HTTP server (thus not nescesarily the Servlet container), and then 'know' that references to packaged resources like this must be translated to references the HTTP server understands. Hmmmm. Big problem with this all, is that it's not gonna be pretty. Or... any idea's?
To illustrate: my first go at the tree component had packaged images. I then found out then requesting 50+ times a resource via your servlet engine is not what you want, even for one client.
Eelco
Jonathan Locke wrote:
i think we need to continue to support the ability to include web
pages, images and other resources on the classpath because we need
to be able to jar up components with their whole resource set. i
believe this worked last time i looked...
------------------------------------------------------- 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-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
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-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
------------------------------------------------------- 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-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
