**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
