Hi Martin, many thanks for your efforts!
Unfortunately this isn't a priority for our team at the moment. I'll get back to you if/when we dig deeper into this matter. Cheers Lasse 2016-06-08 22:04 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > 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 > >> > > > > > >> > > >> > > > > > >> > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > >> > > > > >