Google Web Toolkit

Tuesday, December 30, 2014

Re: how not to cache background image?

The image must not be loaded on every access! I only want to force a reload when I change it, not on every request.

Cache-Control: public, max-age=0, must-revalidate

is exactly this. "public" means the resource is generally cacheable. "max-age=0" means that the cached resource will be marked stale immediately after it has been cached, "must-revalidate" means the browser/cache needs to make a request to your server to figure out if the content has changed in case the resource is marked stale. If new content is available it will be loaded, otherwise the cached resource will be used (and immediately marked stale again because of max-age=0 so the next time the browser/cache needs to revalidate again).

I think from an RFC point of view that is the same as Cache-Control: no-cache however some browsers seem to treat "no-cache" as literally "do not cache that file at all" instead of "cache it but always revalidate its content".

See chapter 14.9 and the following: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Strange Behavior from scheduleIncremental

Browser: Firefox 25

GWT: 2.5

I'm changing the implementation of a scatterchart I have to update incrementally to avoid the slow script warning. I've successfully implemented this using Scheduler.scheduleIncremental. However, there is one oddity I'd like to better understand: The chart is only updated when the user is actively performing input e.g. moving the mouse, but it does not progress if no input is performed at all, though the browser UI is not hung. Is this behavior a setting I've missed? A (potentially fixed in 2.6 or 2.7) GWT bug? Something else?

I'd really appreciate any insight others could provide into this behavior.

Re: Performance impact of Focus panel with no handlers?

Ah, thanks. Good to know.
What about all those little hidden <input tags, also negligible?

Hm yeah well that carries some overhead if you don't need access key support for your focus panels. But if you need access key support then it is kind of a requirement in most browsers as you normally can not assign an access key to a div element.

In HTML5 the accesskey property is allowed on any element not just a, button, various inputs. But I don't know how well browsers already support that. But in the future that input hack might go away for HTML5 compliant browsers.

-- J.

Re: how not to cache background image?

On Tuesday, December 30, 2014 5:06:08 PM UTC+1, Thomas Broyer wrote:

Do you send appropriate HTTP headers to instruct the browser to check for changed content? (e.g. Cache-Control: must-revalidate)

No, but while retrieving information about these headers I noticed another requirement:

The image must not be loaded on every access! I only want to force a reload when I change it, not on every request.

Is there a solution for this?

Magnus

Re: Performance impact of Focus panel with no handlers?

Ah, thanks. Good to know.
What about all those little hidden <input tags, also negligible?

~~~
Thomas & Bertines online review show:
http://randomreviewshow.com/index.html
Try it! You might even feel ambivalent about it :)

On 30 December 2014 at 17:03, Jens <jens.nehlmeier@gmail.com> wrote:

Generally I think they won't really cost you more performance than using a normal panel. FocusPanel just adds a bunch of (delegate) methods you can call and thats it. If your code never calls them then they are likely to be removed by the GWT compiler anyways.

-- J.

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/Nvy8OOBn8sE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: how not to cache background image?

On Tuesday, December 30, 2014 3:51:16 PM UTC+1, Magnus wrote:

Hi,

thanks, but then I have to change and redeploy the code. The reason for using the symbolic link was to be able to change the image independent of the app.
Is there another solution?

Do you send appropriate HTTP headers to instruct the browser to check for changed content? (e.g. Cache-Control: must-revalidate)

Re: how not to cache background image?

thanks, but then I have to change and redeploy the code. The reason for using the symbolic link was to be able to change the image independent of the app.
Is there another solution?

Rename the image to something like bg.nocache.jpg. Your server should already have a rule configured to provide no-cache HTTP headers for anything that contains *.nocache.* because of your <module>.nocache.js file which should also never be cached by browsers.

-- J.