anti cache split panel code


EDIT:
I’m positive about this bug, while i click other buttons on my UI, as long as i don’t call a setSecondComponent() (which nulls the existing reference), and click back on the link, i don’t get a 1.5K, i get a 69B. Furthermore, that object is bound to get way bigger!


EDIT2:
As i learned more about browsers caches i realised that you should be able, with the help of client side terminal, to inject arrays of data with innerHTML or something, and maybe fool the browser to cache it along with this file: http://localhost:8080/realloto/VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/26B52524698EF5E6357600D6DE5E0BE0.cache.html in a separate area meant for static data.

The problem code is this:

/**
     * Removes the component from this container.
     * 
     * @param c
     *            the component to be removed.
     */
    @Override
    public void removeComponent(Component c) {
        super.removeComponent(c);
        if (c == firstComponent) {
           [color=#FD0000]
 firstComponent = null;
[/color]
        } else {
            [color=#FF0000]
secondComponent = null;
[/color]
        }
        requestRepaint();
    }

because i do this:

if (sumsAnalysis == null)
					sumsAnalysis = new SumsAnalysis();
				splitPanel.setSecondComponent(sumsAnalysis);

What happends here is i keep my object reference server side, because when the user makes this event again, he should reuse the object, not create a new one. But instead because the reference is set to null when replacing one of the sides of the split panel, it’s made available for the Garbage Collector, and also breaks Vaadin’s server side component status, resulting in loss of cache, because a new server side component also means a new client side component i assume.

Weirder though, there is some caching going on, as explained along with the picture:
-first 1.5K is from a button click that enters the above logic
-second click is for making the same event from same button, although only 69B are sent

-524B, 151B and 69B are clicks on another button with the same logic as above, that loads something else that’s lighter



-fifth click is on the first button that should refer to the same object (now that’s been initialized for sure it jumps directly to setSecondComponent), but instead it loads it again, because the object has been made null by the splitPanel removeComponent, although it probabably now references the same server side object probably it’s been assigned a new Vaadin component id or something too, so it considers it should load another for the client.


-subsequent click can be identified by the size, and another type of caching has clicked into place, because the some loading times are lower (or firebug’s buggy).

Same goes for the second component in this test, although it has a different behaviour (but is empty itself), caching in 3 stages?
11353.png
11354.png