HI Lasse, I've checked again Wicket Bootstrap code and I see that it works only with LessSource$URLSource class which have lastModifiedDate. I'll need more info (or a demo app) how exactly you use StringSource so I can think for improvement.
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, May 30, 2016 at 4:38 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi Lasse, > > > https://github.com/SomMeri/less4j/blob/master/src/main/java/com/github/sommeri/less4j/LessSource.java#L365 > > StringSource doesn't have get/set lastModifiedDate. > I can add a specialization of this class in Wicket Bootstrap Less project > and make use of it while calculating the last modified for a LessSource and > all its imports. > Then the application should use my version instead of the Less4j one. > If you think this is a good solution then please open an issue at > https://github.com/l0rdn1kk0n/wicket-bootstrap/ > A Pull Request will be awesome! > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, May 25, 2016 at 3:54 PM, Lars Törner <lars.tor...@gmail.com> > wrote: > >> Hi Martin, Bas and others! >> >> Unfortunately I got one crucial thing wrong when I described our scenario. >> >> "A less-variable (put in a separate file) gets a new value." >> >> This is not the case, the variable is changed in code and not in a file. >> This means that even though we have changed a less variable and >> regenerated >> the css, the less files themselves has not changed (no new modification >> time), and therefore the problem we have arises. >> >> To touch the css-file might be a work around, but it seems kind of a >> strange way to handle things. >> >> Cheers >> Lasse >> >> 2016-05-25 12:35 GMT+02:00 Bas Gooren <b...@iswd.nl>: >> >> > Lars, Martin, >> > >> > >> > Sorry for hijacking this thread (sort of). >> > >> > >> > Hmmm, I am 100% sure it was not working for us in a web app we currently >> > have running. >> > >> > I just checked which version of wicket-bootstrap-less it uses (version >> > 0.9.11), and that version already has the recursive check on the >> > last-modified time of imported sources. >> > >> > >> > I’ll try to do some debugging to see if it really is not working, and if >> > that’s the case: why it’s not working. >> > >> > Met vriendelijke groet, >> > Kind regards, >> > >> > Bas Gooren >> > >> > Op 24 mei 2016 bij 20:25:52, Lars Törner (lars.tor...@gmail.com) >> schreef: >> > >> > 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 >> > > > > > >> > >> > > > > > >> >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> > >> > >
