Hi Martin! We have now implemented this solution and we're using bootstrap-less - thanks for that!
But we have a little problem... The browser does not recognize when the css has changed, the cause seems to be that the newly generated css is placed in a file with the same name as before. The name has a hashsum in the name that is generated from the less-file and the less file has not changed. What happens is: A less-variable (put in a separate file) gets a new value. This triggers the less compiler to re-generate css The name of the file with generated css has the same name as before so the browser decides to use its cached version instead. (I'm not the developer of this issue, but hopefully I got it right...) Any suggestions? Cheers Lasse 2016-03-01 13:02 GMT+01:00 Lars Törner <lars.tor...@gmail.com>: > 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 >> > >> > >
