On Tue, May 26, 2009 at 4:41 AM, Martijn Dashorst < martijn.dasho...@gmail.com> 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). Yep. > The relative paths are just that: relative, and they always map to the > absolute same resource URI. I think I'm missing something here. If one uses the regular webapp location to storee css, as I mentioned, http://localhost/a/b requesting css/styles.css will request a different file than http://localhost/a/NOTbrequesting the same css/styles.css. Relative paths will NOT map to the same absolute resource URI. IN the first example, the file webapps/a/b/css/styles.css is retrieved. In the second example, webapp/a/NOTb/css/styles.css is retrieved. In both files, I've used the <link href="css/styles.css" ... > 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. Ahh .... I thought quite the opposite. If I have files src/main/java/a/b/Page.java src/main/resources/a/b/Page.html src/main/resources/a/b/css/styles.css and Page.html includes this: <wicket:link> <link rel="stylesheet" type="text/css" href="css/standard/common.css" /> <link rel="stylesheet" type="text/css" href="css/standard/header.css" /> </wicket:link> it turns into this: <link rel="stylesheet" type="text/css" href="resources/org.effectiveprogramming.effprog.web.markup.layout.BasicLayout/css/standard/common.css"/> which always works. In my eyes, I am giving Wicket just enought information to find my css files. How Wicket decides to encode the <wicket:link/> code is none of my business. As long as the contract is adhered to. I give it a very small relative link path in my resources hierarchy and Wicket encodes that and will ALWAYS find it. If Wicket decides to change how <wicket:link/> encodes a resource (changes /context/resources to /context/foobar/) that is fine with me - as long as Wicket keeps reading in the resources correctly. You imply that, given my aforemetioned files, <wicket:link> <link rel="stylesheet" type="text/css" href="css/standard/common.css" /> <link rel="stylesheet" type="text/css" href="css/standard/header.css" /> </wicket:link> would break if Wicket changed /context/resources to /context/foobar ... and thats not what I expected. I complete agree with the 'performance' point ... and maybe I just misundertstand your perspective but directly using the <link rel="stylesheet" type="text/css" href="css/standard/common.css" /> and fetching pages from webapp/ seems much more volatile to me than using <wicket:link> <link rel="stylesheet" type="text/css" href="css/standard/common.css" /> </wicket:link> which will be encoded however wicket pleases and always served up from a path relative to the resource including it. -Luther I don't code /context/resources > > > 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 > >
