> > The clean way in my case is as Steve suggested , to use css to display the > image for button.
Thanks for all the inputs. Sorry this has dragged out a bit. In my case, I am not sharing static resources across apps. I'm just looking at the best way for each page in my application to retrieve each of the core, application-wide, application-specific, static resource files (js, css, gif, jpg, etc). I might have common.css, header.css, footer.css. Maybe that falls under "keep it with the source" -- which works just fine / albeit somewhat limiting. So maybe the point is moot and <wicket:link/> is the solution for my case. I think physically dropping files in webapp/**/*.css is just fine. I'm really just suggesting the idea of making a robust, infallible way to refer to them that can be written and included just once (in an abstract BaseLayoutPage) and never talked about again :) ... and was entertaining the idea of using the webapp/ directory for this. The suggested IHeaderContributor solution has a few problems in my case. If a developer adds a page 6 mos from now and mounts it to a new, arbitrary URL, */products/cable/offer* - I'd like the css files to all show up - automatically. Unfortunately, IHeaderContributor will not dynamically refer to the original css/styles.css pages. The paths are just echo'd as entered which means ... the single css isn't found. My other made up example - if Wicket (for whatever reason) decides that 1.5 should default to RESTful URLs, would also break anywhere people were hardcoding <link href="css/styles.css" ... since the new RESTful URLs wouldn't look in the proper location. On the other hand, <wicket:link/> continues to work through all of these changes - with no effort or manual management. My initial posts/examples were around <c:url value="/css/styles.css"/> when included on base base pages, always works no matter what page the user has navigated to ... no matter how deep or shallow the url is. It creates an ABSOLUTE path that simply prepends the context the app is deployed to (which, is free to change or go to root). For what its worth, I think that provides some amount of value to my app. For my specific case, I think Igor's suggestion of a tag like <wicket:context/> hit the nail on the head. I can't tell if the other suggestions here are just workarounds or really trying to address my specific use case. IHeaderContribute (thanks for including) doesn't actually do much more than hardcode a fixed path in the markup. Incidentally, I looked - and man, there are alot of pieces to <wicket:link/> :-) Is there an online tutorial for, not just writing components, but implementing a markup component like <wicket:link/>? Ahhhh ... thanks, -Luther
