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
>
>

Reply via email to