it may be helpful to create <wicket:context> analog of <wicket:link>, we already have the framework for getting the path prefix to get to context path.
this is of course only useful for application-specific resources as those will not be reused across projects. in our case our SA extracts the war and copies everything but WEB-INF to apache so all those static application resources can be served there. -igor On Tue, May 26, 2009 at 2:41 AM, Martijn Dashorst <[email protected]> wrote: > Why wouldn't it be a viable solution? It gives you the opportunity to > let the resources be served by your container, which should be > speedier than letting wicket handle it (such requests are filtered > through and go to your container). > > The relative paths are just that: relative, and they always map to the > absolute same resource URI. In fact, they are more stable than serving > things from your classpath, as those resources are served from the > path /context/resources/...., and if we decide to call that path > /context/foobar/.... all your reasoning about stability goes out the > window. > > Martijn > > On Mon, May 25, 2009 at 6:38 PM, Luther Baker <[email protected]> wrote: >> **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst < >> [email protected]> wrote: >> >>> or, if these images and css are for your application, and application >>> wide (i.e. all pages include them), you could put them in >>> src/main/webapp/...... >>> >>> and just <link src="style.css" ... /> them in your markup. >>> >>> Martijn >>> >> >> I'd like to pose a design/theoratical thought here .... >> >> I understand that <wicket:link/> does the right thing for resources (like >> stylesheets) kept in the classpath. I love this behavior. >> >> But, as we know, depending on where my browser URL points, the following: >> >> <link href="css/styles.css" .../> >> >> resolves to different locations. For instance, said stylesheet referenced >> from: >> >> http://hostname/context/products/wires/24 >> >> physically resolves to (mavenized) webapps/*products/wires*/css/styles.css, >> whereas from >> >> http://hostname/context/people/hr/judy >> >> resolves to webapps/*people/hr/judy*/css/styles.css >> >> (In part, this is due to our effort NOT to hardcode the context into the >> link's href.) >> >> *Traditionally, I solved this one of three ways:* >> >> 1. Manually manage every application URL and every mapped file and make >> sure that in all cases the relative path is correct. Ugh! For obvious >> reasons - this technique is not maintainable. Large apps back in the early >> days of Struts with hundreds of actions and JSPs, this just wasn't fun. >> 2. JSTL came along and I started to leverage the <c:url tag. For the most >> part, that was a workable solution - the resulting path was 'absolute' but >> it wasn't hardcoded. Essentially, it gives the framework a chance to work >> its magic (if it were to change somehow). >> 3. Today, I use the resource method (<wicket:link/>) which obviates all >> anxiety by simply letting the framework just manage it. >> >> So to your point Martijn, is using webapp/css and directly including <link >> href="css/styles.css" .../> really a good - viable, long-term solution in >> Wicket apps? Understandably maybe today, the default URL mapper in Wicket >> uses query strings and not deep or hierarchical urls - but the important >> term for me here is "today". >> >> What if, in the future, wicket decides to change the default URL mapping >> scheme - maybe become more RESTful. The inertia built up around legacy apps >> using webapp/css may pose a problem. I don't think this is premature >> functionality ... I think links and urls are a here a now thing and that >> building and migrating apps to future versions of frameworks is hard and >> that a loose practice here may come back to bite a developer ... ? >> >> Also, I've not yet mounted urls but I assume if I were to mount URLs - I'd >> have to really manage this webapp/css approach - whereas, the resource >> approach with <wicket:link/> would just keep humming along. >> >> Some may argue that it isn't really *better* to provide multiple ways to do >> the same thing ... take Tapestry for instance and the technical relevance as >> to where markup files can or cannot reside. >> >> This post is indeed a bit philosophical/theoretical - I've often thought >> about this topic and wanted to clarify in my mind that maybe, these are >> either moot points, ignored concerns, overthinking on my part ... or just >> not important somehow. As I mentioned, this little detail has always been a >> pain point in my previous work and I've just been happy as a lark to use the >> <wicket:link/> which protects me from whatever the future provides. I'm just >> surprised it isn't the suggested best practice or that dropping files into >> webapp/* is *ill*-advised since it assumes something about how Wicket works. >> >> Thanks, >> >> -Luther >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.3.5 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
