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 <lutherba...@gmail.com> wrote: > **On Mon, May 25, 2009 at 2:34 AM, Martijn Dashorst < > martijn.dasho...@gmail.com> 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
