Thanks a lot for the advice below! Ok, in that case, and since I'm still having troubles with getting my resources to be prepended correctly with the context (I still haven't had time to look into the problem in detail) I'll just go with the external approach.
If the problem pops up again (meaning that it's NOT just me ;-), let me know and I'll try to help figure it out. Thanks again! On Mon, 2006-03-06 at 00:14 -0800, Eelco Hillenius wrote: > Generally, (1) is nice for when you are creating custom component, > which you want to be able to reuse in any context/ page without have > to know about it's resources. It'll be all nice encapsulated in that > component. > > (2) however is best for performance and might be handy when you want a > seperate web designer work on it without having to know about how java > source code is structured etc. And concerning your repitition: if with > (1) you would have a lot of components that use the same resources, it > might be easier to avoid duplication by using (2). though you can > always decide on putting everything in a seperate package, and > reference to that (relative) package from your custom components. Also > pro (2) is that you'll never have to register the resources you use > (and it's a deliberate choice in Wicket to force you to do so when > working with Wicket shared resources). > > Eelco > > On 3/6/06, David Leangen <[EMAIL PROTECTED]> wrote: > > > > I am thinking now about packaging together all my various resources > > (images, css, etc.) to avoid repetition. I am hoping that people with > > experience can give me some advice. > > > > > > Basically, I see two ways of doing this. > > > > (1) I create a separate project, with its own place in svn, that can be > > packaged as a JAR and included in each of my Wicket apps. > > > > Or (2) I could just make them available at some public URL so that my > > various apps can simply include the URL to the resources without > > actually including them in the distribution. > > > > > > Other than for development, I don't plan on distributing the web > > applications, so the apps don't need to work in a local (non-connected) > > environment. > > > > > > Advice as to the better approach, or any other suggestions would be > > greatly appreciated. > > > > Thanks! > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > > that extends applications into web and mobile media. Attend the live webcast > > and join the prime developer group breaking into this new coding territory! > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > > _______________________________________________ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
