Thank you, but that doesn't quite accomplish what I was hoping for, since (a) I'd have to change all the HTML files, and (b) the images are not, in fact, in the same directory as the HTML (or a subdirectory of that location).
Also, I didn't mention it before, but it is useful to be able to programmatically get ahold of these images in addition to loading them directly from markup. Bng On Jan 17, 2013, at 8:13 AM, Martin Grigorov wrote: > All you need is to wrap it in <wicket:link><img > src="img/logo.png"/></wicket:link> > This way Wicket will search for img/logo.png in the same folder where the > current .html is. > > > On Thu, Jan 17, 2013 at 2:52 PM, Boris Goldowsky <[email protected]>wrote: > >> Hi all - >> >> Trying to upgrade a number of wicket applications from 1.4 to wicket 1.5, >> and then once that's working, to 6.x. >> >> One thing we want to handle is having any reference in the markup such as >> <img src="img/logo.png"/> be able to find that image in a filesystem >> directory known to the application. There are also js and css >> directories. These are not inside WEB-INF, not in the classpath or >> anything like that, just out in the server's filesystem. >> >> In Wicket 1.4 we handled this as follows: >> Add the parent directory of img, js, and css to >> getResourceSettings().addResourceFolder(...) >> Define a subclass of URIRequestTargetUrlCodingStrategy whose decode() >> method did this: >> return new ResourceStreamRequestTarget(new >> PackageResourceStream(Application.class, "/" + getMountPath() + "/" + path)) >> and set some caching headers. >> Mount this URIRequestTargetUrlCodingStrategy on the "img" path, the "js" >> path, and the "css" path. >> >> >> I am not sure how to accompish this in 1.5 or 6.x. Can someone help me >> either translate the above strategy, or point out how to use the new >> request-mapping setup to make it simpler and clearer? >> >> BTW I did study >> http://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/ , but >> that is for dynamic images. Great for database images, but it does not >> take advantage of wicket's understanding of files - their modification >> dates, caching strategies, determining their mime types, etc. I feel like >> what I want is a superclass of PackageResource that understands files but >> does not make the "package" assumption - but there is no such superclass. >> >> Bng >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com <http://jweekend.com/> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
