I had the exact same problem and I went a diff route: 1) Have designer lay out everything and create whatever tree structure they like/can understand. Use relative paths only. 2) Deploy it into your environment as a folder. (I suggest some version control since you both will be editing them). 3) Overwrite the load path for wicket to some context where these files are located. I am using the root of the site to simplify it. (tutorials-o-plenty on resource loading).
This way all the content is served by the servlet container. And files are "where they left them". There are a BUNCH of tutorials on how to load resources from elsewhere. But I HIGHLY suggest to not use this for "reusable" components and go with Wicket's way of storing it all in one place. Your designers can still change it's look by way of CSS. This is probably THE most common question in these forums. Perhaps something should be done to simplify this.... Maybe I'll create something that does this and send it to Igor for review. Though he'll probably yell at me for promoting bad behavior. ;) - Alex -----Original Message----- From: Steve Swinsburg [mailto:steve.swinsb...@gmail.com] Sent: Monday, December 21, 2009 5:36 AM To: users@wicket.apache.org Subject: Re: Location of css and js files None of these solutions are going to do what the OP really needs since they all assume an app server is serving the pages. Presumably he wants the designer to be able to run up the static HTML in the browser, without running in a web application. You have a few options: 1. link the files as siggested before, ie the HTML knows where the CSS lives and references it normally. If you don't want to have to adjust it later, put it in the same directory as the classes and HTML. You won't need to start the webapp to modify it. 2. Do it in a normal webapp structure as you suggested with the javascript and css directories, and use the Wicket provided HeaderContributor to load it. You'll need to deploy the webapp, but your designer can edit the HTML live if he edits the deployed structure. This approach isn't the greatest since if the webapp is redeployed it will be overwritten. I dont think there is a neat way to do it offline but still in the Wicket way, without having it all with the classes. cheers, Steve On 21/12/2009, at 8:19 PM, Alex Objelean wrote: > > > Hi! > You can use wro4j to load css & js resources from anywhere (even from > classpath, servlet context relative location or disc location). Another > advantage is that the resources are merged and minified, thus greatly > improving the response time: > http://code.google.com/p/wro4j/wiki/GettingStarted > > Alex Objelean > > > dale77 wrote: >> >> >> Hi Alex, >> >> I'm after best practice for css/img and js locations. >> >> I know there are many ways to do something, I'm after a recommendation >> as to what is the best way to do this in wicket. >> >> The way that allows the html markup to be opened by the web designer >> showing the same page view that appears at runtime. >> >> Thanks >> >> Dale >> >> >> -----Original Message----- >> From: Alex Rass [mailto:a...@itbsllc.com] >> Sent: Monday, 21 December 2009 5:03 p.m. >> To: users@wicket.apache.org >> Subject: RE: Location of css and js files >> >> Global resources you can reference "globally". Use can use the >> non-wicket links. Container hosts folders you can use. >> >> Idea behind this is to use components which are fully contained. Hence >> (all in one place). If this doesn't suit you - there are bunch of >> tutorials on how to load resources from elsewhere. >> >> - Alex >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> > > -- > View this message in context: http://old.nabble.com/-announce--wicket-1.4.5-released-tp26868988p26871530.h tml > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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