changing tabsheet problem

In response to a tree select, i create e new tabsheet and put it in second position of a split panel.
The problem is that:

  1. In both IE and FF it does a refresh. In FF whole UI dissapears then appears fast (when having cache disabled), in IE7 the whole UI gets blocked, while the icon of the browser tab indicates a refresh. When FF has cache enabled it stops the screen flicker but it doesn’t cache anything. I’m pretty sure it doesn’t get cached for IE7 either.

  2. It generates traffic to the server, although it’s an empty control, that could’ve been cached.

  3. When i click on its empty tabs it generates traffic again.

EDIT: this code isn’t suppose to come from the server each time, it’s supposed to get cached.

if (value.equals("Sums")) {
				splitPanel.setSecondComponent(new SumsTabSheet());
			} else if (value.equals("Parities")) {
				splitPanel.setSecondComponent(new ParitiesTabSheet());
			} else if (value.equals("Numbers")) {
				splitPanel.setSecondComponent(new NumbersTabSheet());

EDIT (the following didn’t change things one bit):

if (value.equals("Sums")) {
				if(sumsTabSheet == null)
					sumsTabSheet = new SumsTabSheet();
			} else if (value.equals("Parities")) {
				if (paritiesTabSheet == null)
					paritiesTabSheet = new ParitiesTabSheet();
			} else if (value.equals("Numbers")) {
				if(numbersTabSheet == null)
					numbersTabSheet = new NumbersTabSheet();

EDIT2: this didn’t change anything either:


first picture is tabsheet traffic, second is tab traffic.

Found an identical problem in the Sampler:

when clicking on the tree to access this, my whole screen goes white for a sec.

Replication steps:

  1. Click on another control demo in the tree, take “Inline date selection’ for instance”
  2. Click back on “Date selection, locale”

This one doesn’t seem to replicate in IE7 just FF3.6 on my machine.

I didn’t see the problem in FF3.6/OSX. Maybe it’s just a problem on Windows?

Considering that the ‘Date selection, locale’, is the only control in the sampler that redraws the whole browser client area (resulting in a blank one before the new one), i don’t think it’s the operating system.

Anyway, my stuff:
Acer Aspire 5735Z dual-core T3200 at 2GHz, 667MHz FSB, 1MB L2 cache, 2GB DDR2
Windows XP Professional SP3
Firefox 3.6.6

In that particular example, I believe when the locale (might) change, the UI has to be redrawn as the locale change could affect just about everything.

Maybe the example is a little too aggressive about re-telling the client which locale to use, but I would consider it a very minor annoyance to very few people with that particular example. Furthermore, it is an issue you would be very unlikely to encounter in any real application - typically locale or language change is a more global and explicit operation anyway, and the new locale is then kept unchanged throughout the life of the application.

The browser cache has nothing whatsoever to do with caching components (but the bulk of the widgetset javascript and the theme contents are cached) - the component updates are transmitted as JSON when needed.

Caching pieces of the UI that have already been seen by the client is up to the implementation of the particular component and its client-side widget. Some of the standard components do cache more than others, but this is also a compromise with respect to client side memory usage, and e.g. on a TabSheet you could (and often do in many real-world applications) have large, complicated layouts on each of a large number of tabs.

I don’t remember exactly how TabSheet behaves, but I believe it does not try to cache much but instead might re-fetch the content from the server upon tab change if needed.

Some changes to the granularity of caching and what exactly is cached may come in Vaadin 7, but every case needs to be evaluated carefully from more than one point of view - responsiveness, memory usage on the client, code complexity and more.

I await further vaadin updates then :slight_smile:

Even if developers might take some wrong decisions (but don’t see how’s that the case), i don’t think enabling a way for the developer about what should get cached and what not would hurt.

My app has only this priority above all else:
Return fast, this implies caching and reusing everywhere it can be done, and of course keep it simple if possible.
The bottlenecks of a web application that i could notice thus far are the bandwidth and the server CPU/RAM (external memory or HDD almost never been a problem).
And this:
Be AJAX, meaning no page refreshes, ever :grin: Refreshing the whole page for a single component seems a mistake to me, and certainly to he user, who cares even less.

Even more of it, my actual caching problems is about caching the data on the client somehow, by any means, sneaky javascript, browser (actually the ‘GET cache’ isn’t an option but for smallest data sets, because is limited to 4K or something like that), or something else, like the upcoming HTML 5 and client side storage i heard about, and then make the components pick that cache up. It comes to me that while picking the data from the cache, the control actually only needs to send a request to the server, notifying that something changed, but the server needs not respond if the data didn’t actually change, thus leaving he client with its cached state, which is perfect.