Thanks for your quick answer Martin! We will look into your suggestions and
get back to you if we have more questions!

2016-03-01 11:49 GMT+01:00 Martin Grigorov <>:

> Hi Lasse,
> I think the easiest would be to save the generated CSS in memory, e.g. in
> YourApplication.
> Once you receive an update from the other system you should just delete the
> cache (entry). I guess you will have to use read lock when serving the
> response and write lock when updating it.
> Wicket uses AbstractResource#dataNeedsToBeWritten()
> <
> >
> method to decide whether the client/browser has the latest version. I.e.
> when the browser makes a request for the CSS you should first check whether
> there is a cached entry for this CSS file. If there is no such then
> generate it, save it in the cache and serve it back. If there is such cache
> entry then let Wicket check its last modification time against the request
> header value for 'If-Modified-Since'.
> Additionally you may want to pre-build the CSS resources at application
> start time, or even preserve the current build-time solution, so it is
> faster for the first users of the application before any changes in the
> variables.
> I've had an issue with similar setup in the past - we were using CDN
> (Akamai) and their request timed out while waiting for the Less
> compilation. For requests from normal browsers this shouldn't be a problem
> though.
> You may also check Wicket Bootstrap Less
> <
> >.
> It is a module of Wicket-Bootstrap project but could be used without the
> other modules.
> It provides most of the features you need. You just need to see how to plug
> the update of the variables.
> Martin Grigorov
> Wicket Training and Consulting
> On Tue, Mar 1, 2016 at 10:45 AM, Lars Törner <>
> wrote:
> > Hi!
> >
> > We would like to be able to set new colors in our gui at runtime, i.e.
> > change the theme.
> > We use less on component basis. To day we compile the less files to css
> at
> > buildtime and these becom packacke resources.
> >
> > Now we would like to change the colors by altering the appropriate
> > less-variables. We want to set the colors (just values as - themeColor =
> > #000000) in our legacy application. Our web app lives in another
> > servletcontainer than the legacy applicaton, so one apporach is to fetch
> > the new colors by REST (for example check for new colors once a minute)
> and
> > get them as json in our wicket-web-app.
> >
> > Now we're thinking of using dynamic resources. i.e. do not compile the
> > less-files at build-time, instead generate css-files fom the less files
> > (hooking in a less-preprocessor) per component at runtime when requested.
> >
> > We don't want to generate the css-resource and send it to the client if
> > it's already cached in browser and not updated on server.
> > We don't want to generate the css if it has already been done for the
> > component and new colors hasn't been set, i.e once a dynamic resource is
> > generated, a cached version should be given as response for all clients
> > that request the component.
> >
> > Now the question is if the right way to do this is by implementing a
> > dynamic resource by extending AbstractResource and to cache the css
> (output
> > a css-file on disk?, cache in application?) when once generated?
> >
> > Any drawbacks? Performance issues? Is there a better way to do it?
> >
> > Cheers
> > Lasse
> >

Reply via email to