You may have to look at this case by case ... In this example, what are you doing with the input field? Submitting a form?
Were that the case, how about using a raw input tag and moving any wicket logic to the submit handler? -Luther On Tue, May 26, 2009 at 6:02 PM, Vasu Srinivasan <vasy...@gmail.com> wrote: > I too have been trying to find the right way about where to put the > resources (image, css, js). I work in an environment where the > images/css/js > are maintained by a separate team and is in apache server as they are > reused > across several apps/projects in different app servers. So putting it as > part > of the application is a no-no (src/main/resources or src/main/webapp etc.) > . > It doesn't work that way though -- I tried using a ImageButton without > passing the new ResourceReference() in the constructor. > > My html is like: > > <input type="image" wicket:id="imageId" src="/images/button.gif" /> > > Wicket replaces the html with <input type="image" > src="resources/.....//images/button.gif" /> and obviously does not find it. > > Is there a clean way out of this? (ie not prepend resources/... etc) > > Thanks! > Vasya > > > On Tue, May 26, 2009 at 12:40 PM, Luther Baker <lutherba...@gmail.com > >wrote: > > > I like that idea! > > > > > > On Tue, May 26, 2009 at 10:33 AM, Igor Vaynberg <igor.vaynb...@gmail.com > > >wrote: > > > > > 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 > > > <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). > > > > > > > > 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 > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > -- > Regards, > Vasu Srinivasan >
