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 <mgrigo...@apache.org>: > 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 > > >
