You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Lars Törner <la...@gmail.com> on 2016/03/01 10:45:21 UTC

Generate css from less for package resources at runtime.

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

Re: Generate css from less for package resources at runtime.

Posted by Lars Törner <la...@gmail.com>.
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 <mg...@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 <mg...@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 <la...@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 <ba...@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.torner@gmail.com)
> >> schreef:
> >> >
> >> > Thanks Martin, I'll take a look at it!
> >> >
> >> > tisdag 24 maj 2016 skrev Martin Grigorov <mg...@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.torner@gmail.com
> >> > > <javascript:;>> wrote:
> >> > >
> >> > > > Thanks, we'll try this!
> >> > > >
> >> > > > Cheers
> >> > > > Lasse
> >> > > >
> >> > > > 2016-05-18 13:21 GMT+02:00 Bas Gooren <bas@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 (
> >> mgrigorov@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.torner@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.torner@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 <
> >> mgrigorov@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.torner@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
> >> > > > > > >> >
> >> > > > > > >>
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> >
> >>
> >
> >
>

Re: Generate css from less for package resources at runtime.

Posted by Martin Grigorov <mg...@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 <mg...@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 <la...@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 <ba...@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.torner@gmail.com)
>> schreef:
>> >
>> > Thanks Martin, I'll take a look at it!
>> >
>> > tisdag 24 maj 2016 skrev Martin Grigorov <mg...@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.torner@gmail.com
>> > > <javascript:;>> wrote:
>> > >
>> > > > Thanks, we'll try this!
>> > > >
>> > > > Cheers
>> > > > Lasse
>> > > >
>> > > > 2016-05-18 13:21 GMT+02:00 Bas Gooren <bas@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 (
>> mgrigorov@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.torner@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.torner@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 <
>> mgrigorov@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.torner@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
>> > > > > > >> >
>> > > > > > >>
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> >
>>
>
>

Re: Generate css from less for package resources at runtime.

Posted by Martin Grigorov <mg...@apache.org>.
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 <la...@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 <ba...@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.torner@gmail.com)
> schreef:
> >
> > Thanks Martin, I'll take a look at it!
> >
> > tisdag 24 maj 2016 skrev Martin Grigorov <mg...@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.torner@gmail.com
> > > <javascript:;>> wrote:
> > >
> > > > Thanks, we'll try this!
> > > >
> > > > Cheers
> > > > Lasse
> > > >
> > > > 2016-05-18 13:21 GMT+02:00 Bas Gooren <bas@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 (mgrigorov@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.torner@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.torner@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 <
> mgrigorov@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.torner@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
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
>

Re: Generate css from less for package resources at runtime.

Posted by Lars Törner <la...@gmail.com>.
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 <ba...@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.torner@gmail.com) schreef:
>
> Thanks Martin, I'll take a look at it!
>
> tisdag 24 maj 2016 skrev Martin Grigorov <mg...@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.torner@gmail.com
> > <javascript:;>> wrote:
> >
> > > Thanks, we'll try this!
> > >
> > > Cheers
> > > Lasse
> > >
> > > 2016-05-18 13:21 GMT+02:00 Bas Gooren <bas@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 (mgrigorov@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.torner@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.torner@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 <mgrigorov@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.torner@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
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>

Re: Generate css from less for package resources at runtime.

Posted by Bas Gooren <ba...@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.torner@gmail.com) schreef:

Thanks Martin, I'll take a look at it!

tisdag 24 maj 2016 skrev Martin Grigorov <mg...@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.torner@gmail.com
> <javascript:;>> wrote:
>
> > Thanks, we'll try this!
> >
> > Cheers
> > Lasse
> >
> > 2016-05-18 13:21 GMT+02:00 Bas Gooren <bas@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 (mgrigorov@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.torner@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.torner@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 <mgrigorov@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.torner@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
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Generate css from less for package resources at runtime.

Posted by Lars Törner <la...@gmail.com>.
Thanks Martin, I'll take a look at it!

tisdag 24 maj 2016 skrev Martin Grigorov <mg...@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.torner@gmail.com
> <javascript:;>> wrote:
>
> > Thanks, we'll try this!
> >
> > Cheers
> > Lasse
> >
> > 2016-05-18 13:21 GMT+02:00 Bas Gooren <bas@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 (mgrigorov@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.torner@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.torner@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 <mgrigorov@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.torner@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
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Generate css from less for package resources at runtime.

Posted by Martin Grigorov <mg...@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 <la...@gmail.com> wrote:

> Thanks, we'll try this!
>
> Cheers
> Lasse
>
> 2016-05-18 13:21 GMT+02:00 Bas Gooren <ba...@iswd.nl>:
>
> > 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 (mgrigorov@apache.org)
> > 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 <la...@gmail.com>
> > 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 <la...@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 <mg...@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.torner@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
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: Generate css from less for package resources at runtime.

Posted by Lars Törner <la...@gmail.com>.
Thanks, we'll try this!

Cheers
Lasse

2016-05-18 13:21 GMT+02:00 Bas Gooren <ba...@iswd.nl>:

> 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 (mgrigorov@apache.org)
> 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 <la...@gmail.com>
> 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 <la...@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 <mg...@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 <la...@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
> > >> >
> > >>
> > >
> > >
> >
>

Re: Generate css from less for package resources at runtime.

Posted by Bas Gooren <ba...@iswd.nl>.
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 (mgrigorov@apache.org) 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 <la...@gmail.com> 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 <la...@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 <mg...@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 <la...@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  
> >> >  
> >>  
> >  
> >  
>

Re: Generate css from less for package resources at runtime.

Posted by Martin Grigorov <mg...@apache.org>.
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 <la...@gmail.com> 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 <la...@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 <mg...@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 <la...@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
> >> >
> >>
> >
> >
>

Re: Generate css from less for package resources at runtime.

Posted by Lars Törner <la...@gmail.com>.
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 <la...@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 <mg...@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 <la...@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
>> >
>>
>
>

Re: Generate css from less for package resources at runtime.

Posted by Lars Törner <la...@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 <mg...@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 <la...@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
> >
>

Re: Generate css from less for package resources at runtime.

Posted by Martin Grigorov <mg...@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 <la...@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
>