Additionally we used preloading of static resources. At app start time (i.e. MyApp#init()) we fired an artificial request to all registered CSS/JS bundles. The response has been cached (by a specialization of ConcatBundleResource) and later all real/runtime requests were using the cache. This way the compression (CSS & JS) has been done just once. By default Wicket would do it for each request.
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Feb 2, 2015 at 10:43 AM, Tobias Soloschenko < tobiassolosche...@googlemail.com> wrote: > Good idea, I'm going to make it this way! > > kind regards > > Tobias > > > Am 02.02.2015 um 09:36 schrieb Martin Grigorov <mgrigo...@apache.org>: > > > > Hi Tobias, > > > > I imagine it with a regex that parses for "url(...)" and replaces the old > > url with a new one. > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Mon, Feb 2, 2015 at 10:31 AM, Tobias Soloschenko < > > tobiassolosche...@googlemail.com> wrote: > > > >> Hi, > >> > >> would be a good to see such an implementation out of the box. > >> (CSSCompressor) > >> > >> I try to do it soon - maybe with a varags of URLs which are going to be > >> passed into the CSS file. > >> > >> kind regards > >> > >> Tobias > >> > >>> Am 02.02.2015 um 08:35 schrieb Martin Grigorov <mgrigo...@apache.org>: > >>> > >>> Hi, > >>> > >>> Putting your static resources in the context root and letting Wicket > >> manage > >>> them is not a problem. > >>> For example you can use a special/custom MyScope.class as a scope for > >>> JS/Css ResourceReferences and a custom IResourceFinder that uses > >>> ServletContext#getResource() when the scope is MyScope.class. > >>> > >>> The problem with images in .css files is that they are processed by > >> browser > >>> directly. I.e. they are "invisible" to Wicket. The CSS is streamed to > the > >>> browser and the browser resolves the relative url to absolute one and > >> makes > >>> a new request for the image. > >>> > >>> One way to make it working is to use a custom ICssCompressor that > >> receives > >>> the raw .css as an input, parses for url(...) and replaces it with the > >> url > >>> produced by urlFor(new PackageResourceReference(MyScope.class, " > >>> the.original.image.name")). > >>> > >>> Another way is to use Less/SCSS/SASS as a pre-processor. I have did > this > >>> with Less in the past: Less4j provides > >> > https://github.com/SomMeri/less4j/blob/master/src/main/java/com/github/sommeri/less4j/LessFunction.java > >> . > >>> With it you can replace some content in the Less file during > compilation. > >>> This approach works only with runtime compilation! > >>> > >>> > >>> Martin Grigorov > >>> Wicket Training and Consulting > >>> https://twitter.com/mtgrigorov > >>> > >>>> On Fri, Jan 30, 2015 at 3:21 PM, Nick Pratt <nbpr...@gmail.com> > wrote: > >>>> > >>>> is it possible to have Wicket manage resources (.css and .js) outside > of > >>>> the classpath, so that we can leverage all the great dev/prod things > >> that > >>>> Wicket does with resources served from within the classpath? > >>>> > >>>> We typically put our resources at the root of the context: > >>>> /assets/css > >>>> /assets/js > >>>> /assets/images > >>>> /WEB-INF/.... > >>>> > >>>> This way we can reference images from within our style sheets using > >>>> 'background:url(../images/logo.png);' > >>>> If Wicket were to serve these resources (I guess we would have to move > >> the > >>>> assets down a level so they were brought in to the accessible > classpath > >> of > >>>> the Wicket app), can we manage such context sensitive references > within > >> CSS > >>>> files that are being managed by Wicket? > >>>> > >>>> We're using 6.x > >>>> > >>>> N > >> > >> --------------------------------------------------------------------- > >> 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 > >
