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() <https://github.com/apache/wicket/blob/ffa34c6bfbd2ccd8340e23ff1601edd3e0e941d6/wicket-core/src/main/java/org/apache/wicket/request/resource/AbstractResource.java#L433> 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 <https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/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 https://twitter.com/mtgrigorov On Tue, Mar 1, 2016 at 10:45 AM, Lars Törner <lars.tor...@gmail.com> 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 >
