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

Reply via email to