Where's the edit button :)
Near the beginning,
"theoratical" should be theoretical.
Near the end,
"I'm just surprised ... that dropping files into webapp/* is
*ill*-advised"
should read
"I'm just surprised ... that dropping files into webapp/* isn't *ill
*-advised"
I'm sure there are more. Thanks,
-Luther
On Mon, May 25, 2009 at 11:38 AM, 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
>
>
