Thanks Martin, I'll take a look at it! tisdag 24 maj 2016 skrev Martin Grigorov <mgrigo...@apache.org>:
> Hi, > > I checked the code last night and I believe this use case should be covered > by > > https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/a64af20bcd65f365dbd487c7480db441fd6b6489/bootstrap-less/src/main/java/de/agilecoders/wicket/less/LessCacheManager.java#L156 > It uses Less4j's APIs to get all imported resources recursively and > extracts the latest modification time. > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, May 18, 2016 at 3:17 PM, Lars Törner <lars.tor...@gmail.com > <javascript:;>> wrote: > > > Thanks, we'll try this! > > > > Cheers > > Lasse > > > > 2016-05-18 13:21 GMT+02:00 Bas Gooren <b...@iswd.nl <javascript:;>>: > > > > > Hi all, > > > > > > We’ve encountered this issue, too; Simple fix is to touch the less > file, > > > even when a secondary file was the only change. > > > > > > The root cause is simple: wicket is not aware of any includes in the > less > > > file, and as such only looks at the “parent” less file to see if it was > > > changed. A potential way to fix this is to make it more intelligent, > > > assuming the less compiler can expose such details (referenced files, > > > last-modified time of those files). > > > > > > Met vriendelijke groet, > > > Kind regards, > > > > > > Bas Gooren > > > > > > Op 18 mei 2016 bij 13:06:59, Martin Grigorov (mgrigo...@apache.org > <javascript:;>) > > > schreef: > > > > > > Hi Lasse, > > > > > > I'll take a look in the coming days! > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Wed, May 18, 2016 at 11:43 AM, Lars Törner <lars.tor...@gmail.com > <javascript:;>> > > > wrote: > > > > > > > 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 > <javascript:;>>: > > > > > > > > > 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 > <javascript:;>>: > > > > > > > > > >> 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 <javascript:;> > > > > > > > >> 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 > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > >
