Admittedly, I think this is slightly out of context here ... but a few days back, Martijn posted (no bashing intended - I try to adhere to this):
"There is no sane reason why anyone would put the html, js, css and properties resources in any place except *next* to the corresponding.java file. Your .java file can not function without the .html file. Your component will fail if the .properties file is not available. When the js file can't be found your component is useless. Wicket goes beyond the call of duty to provide developers with the means to encapsulate your components, bringing Object Oriented design and programming to the web tier. Moving the necessary resources outside the package folder into a separate directory structure breaks this encapsulation is definitely not the Wicket Way (tm)." http://osdir.com/ml/users-wicket.apache.org/2009-03/msg01100.html On Wed, May 27, 2009 at 8:36 AM, Luther Baker <[email protected]> wrote: > Hi Steve, > > Continue your example and mount a url to an existing page that extends > BasePage: > > mountBookmarkablePage("/im/going/home", About.class); > > and tell me what happens to your js and css references when you visit that > url. > > Hope that helps, > > -Luther > > > > On Wed, May 27, 2009 at 7:20 AM, Steve Swinsburg < > [email protected]> wrote: > >> I don't see the issue that you all seem to be experiencing but I can offer >> some advice: >> CSS, Javascript, images etc should be stored in the webapp directory NOT >> mixed in with the rest of the classes and HTML. Your CSS can then get at >> them easily if you are using any background images etc. Martijn mentioned >> this and its a valid point, you can then unmount the directories and let the >> web server serve them statically rather than Tomcat serve them which takes >> up threads. >> >> You can use an IHeaderContributor to add any CSS or Javascript references >> into the HTML header: >> >> public class BasePage extends WebPage implements IHeaderContributor { >> >> public void renderHead(IHeaderResponse response) { >> response.renderCSSReference("css/jquery.cluetip.css");response.renderJavascriptReference( >> "javascript/jquery.dimensions.js"); >> response.renderJavascriptReference("javascript/jquery.hoverIntent.js"); >> response.renderJavascriptReference("javascript/jquery.cluetip.js"); >> } >> >> If you need to add any images in your page, use a ContextImage which is >> relative to the context always. >> >> I tend to use a BasePage which setups the header and have my other pages >> extend BasePage you might find it useful as well. >> >> >> cheers, >> Steve >> >> >> >> >> >> >> On 27 May 2009, at 06:40, Luther Baker wrote: >> >> On Tue, May 26, 2009 at 11:43 PM, Vasu Srinivasan <[email protected]> >> wrote: >> >> @Luther: >> >> >> Yes - I'm using the ImageButton it to submit a form. >> >> >> Thanks for the suggestion to use the modifier. I will try that. >> >> >> >> Great. I think it should work for you. >> >> >> >> On a side note, I thought that having the images/css/js etc served from >> >> webserver is pretty common and would be supported by wicket without having >> >> to add the names within java code. >> >> >> >> If I had to guess ... it is probably just a matter of time. There are >> probably a lot of design and "Wicket Way" considerations the team iterates >> through and prioritizes. I think cases like yours bring some of these >> usage >> points into clearer focus after-which, maybe they'll get some traction. >> >> My guess is that these folks are pretty busy and that there are probably >> 10s >> of 100s of similar requests in the queue - so just need some time ... or >> bodies :) >> >> >> I understand the reasoning behind using new ResourceReference as it makes >> >> loading locale specific images very simple. But why should wicket prepend >> >> classpath etc. -- i'm not clear on that. Can't wicket simply ignore the >> >> "src" attribute if ResourceReference is not present and use whatever was >> >> already in the html template? That way I do not have to specify the image >> >> name within the java code and the separation between java and html is >> >> clean. >> >> >> >> It sounds reasonable to me - but I'm not knee deep in the code either/yet. >> >> -Luther >> >> >> >
