On Feb 22, 8:12 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
On Sun, Feb 21, 2010 at 9:49 AM, Marius marius.dan...@gmail.com wrote:
Guys,
I'm starting to have second thoughts about having css or js combine
(concatenation of multiple files into a single response) on lift side.
I'm
On Sun, Feb 21, 2010 at 9:49 AM, Marius marius.dan...@gmail.com wrote:
Guys,
I'm starting to have second thoughts about having css or js combine
(concatenation of multiple files into a single response) on lift side.
I'm starting to question that real benefits as in production sites in
many
Guys,
I'm starting to have second thoughts about having css or js combine
(concatenation of multiple files into a single response) on lift side.
I'm starting to question that real benefits as in production sites in
many cases the lift app has a http reverse proxy front end that can
serve static
calculating an md5 of a file would induce additional computation time
and we'd need to maintain hashes for each resource file. The prototype
that I have now is a function in LiftRules that by default returns a
random value generated on startup. Applications that needs MD5 per
file could
On Feb 16, 3:55 pm, Alex Black a...@alexblack.ca wrote:
calculating an md5 of a file would induce additional computation time
and we'd need to maintain hashes for each resource file. The prototype
that I have now is a function in LiftRules that by default returns a
random value generated
In my prototype it is a random string generated once at startup. So
this is the same for all css/js references. But this is imposed just
by the default implementation of the LiftRules.attachResourceId
function. A different implementation can generate unique MD5 sequences
based on each
There is no proper API to see when file names are changed unless we
poll. I prefer to have LiftRules function that by default takes a
value generated at startup. User's can override it to generate the
token more frequently depending on their use-case.
I was interested in less-frequently (not
We don't seem to have this problem with images..
Could this have to do with the fact that the CSS files and javascript
are served out of the WAR file, whereas our images are served by a
separate Jetty context?
On Feb 13, 3:35 am, Marius marius.dan...@gmail.com wrote:
On 12 feb., 22:56, Alex
On Mon, Feb 15, 2010 at 10:27 PM, Alex Black a...@alexblack.ca wrote:
We don't seem to have this problem with images..
Could this have to do with the fact that the CSS files and javascript
are served out of the WAR file, whereas our images are served by a
separate Jetty context?
It very well
Is Alex's problem that the browsers update 24 hours later or not at all or
something else?
2010/2/15 Jeppe Nejsum Madsen je...@ingolfs.dk
On Mon, Feb 15, 2010 at 10:27 PM, Alex Black a...@alexblack.ca wrote:
We don't seem to have this problem with images..
Could this have to do with the
That is an option, thanks.
On 14 feb., 04:45, Naftoli Gugenheim naftoli...@gmail.com wrote:
May I suggest that instead of naming the tag 'css,' it be given a name
that's more agnostic of the content it affects and more indicative of what
it does? Technically this could be used for any type of
Naftoli Gugenheim naftoli...@gmail.com writes:
May I suggest that instead of naming the tag 'css,' it be given a name
that's more agnostic of the content it affects and more indicative of what
it does? Technically this could be used for any type of resource.
What about something like
On 12 feb., 22:56, Alex Black a...@alexblack.ca wrote:
If this was implemented, it should be a unique id once per CSS change,
not once per application start.
There is no proper API to see when file names are changed unless we
poll. I prefer to have LiftRules function that by default takes a
On 12 feb., 23:04, Alex Black a...@alexblack.ca wrote:
Yes, that's how it should work if everything was configured correctly
(which I think it wasn't for the OP)
Heh, I'm the OP.
I'll have to dig into why its not working as expected I guess.
But what we were discussing (at least I was
On 13 feb., 18:44, Timothy Perrett timo...@getintheloop.eu wrote:
Seems like this conversation is diverging somewhat.
Can I suggest there are two things in play here, and they address different
problems.
1. Stopping the caching of resource files for an application build; the
proposed
May I suggest that instead of naming the tag 'css,' it be given a name
that's more agnostic of the content it affects and more indicative of what
it does? Technically this could be used for any type of resource.
What about something like
lift:uniqueurl path=url /
Or something else?
Thanks for
Oh yes I did and I hate it. Ironically I was about to propose a
solution for this.
instead of
link rel=stylesheet type=text/css href=mycss.css/
do something like:
lift:css name=mycss.css /
this would render:
link rel=stylesheet type=text/css href=mycss.css?
i784yrfiuhferfhweir57=_/
the
On Fri, Feb 12, 2010 at 7:28 PM, Marius marius.dan...@gmail.com wrote:
Oh yes I did and I hate it. Ironically I was about to propose a
solution for this.
instead of
link rel=stylesheet type=text/css href=mycss.css/
do something like:
lift:css name=mycss.css /
this would render:
link
This is pretty much what rails does. Straight from github:
link
href=/stylesheets/bundle_common.css?7371c81fbc6b010a32fb11b42a0fc322c3c57863
media=screen rel=stylesheet type=text/css /
link
href=/stylesheets/bundle_github.css?7371c81fbc6b010a32fb11b42a0fc322c3c57863
media=screen
Tim please see my proposal above :)
On 12 feb., 21:12, Timothy Perrett timo...@getintheloop.eu wrote:
This is pretty much what rails does. Straight from github:
link
href=/stylesheets/bundle_common.css?7371c81fbc6b010a32fb11b42a0fc322c3c578
63 media=screen rel=stylesheet type=text/css /
Jeppe probably we can combine the two proposals. Perhaps something
like:
lift:css name=mycss.css, some_other.css. /classpath/baz.css /
thus Lift could generate:
link rel=stylesheet type=text/css href=compound_2434rfe34534.css?
i784yrfiuhferfhweir57=_/
compound_2434rfe34534.css is a synthetic
On Fri, Feb 12, 2010 at 11:20 AM, Marius marius.dan...@gmail.com wrote:
Jeppe probably we can combine the two proposals. Perhaps something
like:
lift:css name=mycss.css, some_other.css. /classpath/baz.css /
thus Lift could generate:
link rel=stylesheet type=text/css
I opened
http://www.assembla.com/spaces/liftweb/tickets/346-Solve-CSS-JS-unwanted-caching
Br's,
Marius
On 12 feb., 21:20, Marius marius.dan...@gmail.com wrote:
Jeppe probably we can combine the two proposals. Perhaps something
like:
lift:css name=mycss.css, some_other.css.
On Fri, Feb 12, 2010 at 8:20 PM, Marius marius.dan...@gmail.com wrote:
Jeppe probably we can combine the two proposals.
Yes, that would be natural
Perhaps something like:
lift:css name=mycss.css, some_other.css. /classpath/baz.css /
thus Lift could generate:
link rel=stylesheet
On 12 feb., 21:31, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
On Fri, Feb 12, 2010 at 8:20 PM, Marius marius.dan...@gmail.com wrote:
Jeppe probably we can combine the two proposals.
Yes, that would be natural
Perhaps something like:
lift:css name=mycss.css, some_other.css.
hey guys, I love the enthusiasm, but putting a unique value on the css
filenames seems like a hack, surely we can do better?
Whats supposed to happen is:
- browser requests resource (e.g. styles.css) with a conditonal get
(if newer than X)
- server checks to see if resource is newer than X
- if
I believe IE6 does not follow the correct process you describe and will always
cache CSS files of the same name.
-Ross
On Feb 12, 2010, at 3:48 PM, Alex Black wrote:
hey guys, I love the enthusiasm, but putting a unique value on the css
filenames seems like a hack, surely we can do better?
1. Luckily IE6 is dying out :) unless http://saveie6.com/ works
2. surely even IE6 obeys expires headers or some caching rules?
On Feb 12, 3:48 pm, Ross Mellgren dri...@gmail.com wrote:
I believe IE6 does not follow the correct process you describe and will
always cache CSS files of the same
It does normally, but not for CSS resources. I just did a quick google and I
found one page that said it will send a HEAD for a cached CSS but only when the
browser session is restarted. I know that at my work we've had to do the
filename hack because nothing else works with IE6.
And IE6 may
If this was implemented, it should be a unique id once per CSS change,
not once per application start.
E.g. we deploy to production every few weeks, and client browsers
should be able to cache files that entire time until change them,
regardless of reboots.
But obviously a value once per
I'd vote for: figure out if this can be done properly (e.g. rely on
file system date/time file and HTTP), and if necessary add a hack to
support browsers like IE6.
On Feb 12, 3:54 pm, Ross Mellgren dri...@gmail.com wrote:
It does normally, but not for CSS resources. I just did a quick google and
On Fri, Feb 12, 2010 at 9:48 PM, Alex Black a...@alexblack.ca wrote:
hey guys, I love the enthusiasm, but putting a unique value on the css
filenames seems like a hack, surely we can do better?
Whats supposed to happen is:
- browser requests resource (e.g. styles.css) with a conditonal get
On Fri, Feb 12, 2010 at 9:56 PM, Alex Black a...@alexblack.ca wrote:
If this was implemented, it should be a unique id once per CSS change,
not once per application start.
E.g. we deploy to production every few weeks, and client browsers
should be able to cache files that entire time until
Yes, that's how it should work if everything was configured correctly
(which I think it wasn't for the OP)
Heh, I'm the OP.
I'll have to dig into why its not working as expected I guess.
But what we were discussing (at least I was :-) was more that Lift
should serve resources with an
Or just the MD5 hash of the contents...
ah, now you're talking. That sounds like a good solution.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email
On Fri, Feb 12, 2010 at 10:04 PM, Alex Black a...@alexblack.ca wrote:
Yes, that's how it should work if everything was configured correctly
(which I think it wasn't for the OP)
Heh, I'm the OP.
Ahh sorry :-)
The other option is say you can cache this for like the next hour
but every time
This looks a bit complex:
http://www.samaxes.com/2009/05/combine-and-minimize-javascript-and-css-files-for-faster-loading/
but its an example of how other people have handled combining css and
javascript files.
On Feb 12, 4:11 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
On Fri, Feb 12,
37 matches
Mail list logo
