[AndreiK]

To clarify:

Expires header was in the past (Dec 31, 1969)
Pragma: No-cache
Cache-Control: no-cache
Date: [Correct]

Tomcat doesn't really have any cache-control configuration, so its not something I configured somewhere incorrectly.

Also Cache-Control directives overwrite the Expires ones, as per spec.

[Isomorphic]

OK - not sure what situation you are trying to address, then.

If you take a look at the Showcase or other sites constructed with caching in mind, the Expires header will be set to some time in the future, headers such as "Pragma: No-cache", which disable caching, will of course not be set. We do not know of a benefit of setting "Cache-Control: max-age" if Expires is already set and already a future date.

Perhaps you meant that if you do not have control over other headers because some other system is setting them, you can use Cache-Control to override the behavior implied by the other headers?

[AndreiK]

In essence I am overriding the default header set that the web server is adding for one reson or another.

I did not set any of these headers and the Expires header being automatically set to be in the past obviously invalidated any of the caching that the browser could do.

So what I am addressing is if for whatever reason the server that you deploy your application on is adding undesirable headers that prevent proper caching you may safeguard your Smart GWT resources folder by enforcing certain headers via a filter.

This way when you export your WAR its protected against the containers behaviour (Tomcat in my case)

This is from Apache:

Tomcat adds response headers to protected pages to prevent them from being
cached by proxy servers.

So if I exported my GWT app and deployed it on lets say WebSphere or JBoss instead of Tomcat I wouldn't have this issue, but by having the filter in place for the sc/ folder I can enforce this across all platforms.

[Isomorphic]

Ah OK. Note that the more typical and better performing solution is to exclude static resources (such as SmartGWT skin files) from authentication checks. But if for whatever reason you are deploying to a server where everything is unconditionally protected and you have no control over the server, your workaround could come in handy.

[AndreiK]

That can be cumbersome in certain situations. For example popular authenticators like Jcifs do not support url-pattern exclusion.

[jnelson11]

Hello,

I am experiencing a similar issue with IE slowness that I just cant figure out at this point, and it seems to be a different use case than the ones mentioned in this ticket.

I don't have any problems using 1 ListGrid in IE, this runs at equal speeds in both IE and FF.

The problems however come in when I start using more than one grid on a page. it starts to happen with about 5 grids on a page and then gets exponentially slower as I add more grids. with FF there are no problems with performance. With IE the performance is so bad that you can not even interact with the browser while the grids are loading. I am currently testing this in both IE7 and IE8.

I am using a standard baseline test with basic grids and datasource object that is static on the page.

I have tired some things mentioned in this ticket but others seem irrelevant even though i tried them.

Please let me know if you want to see the demo page that I have setup.

[svjard]

I have an app with many more then 5 grids and it performs acceptably in IE (as far as IE is acceptable). Are your datasources standalone? Shared? Redraws occur how frequently? Most the issues I have ever run into are just the fact IE doesn't do redraws nearly as fast (IE9 supposedly has huge upgrades in this). Also of course low-memory machines (512mb) seem to also have IE issues too.

[jnelson11]

I have about 15 grids that get rendered on the page. My base test loads static data defined on the page.

It appears that even the first draw is extremely slow and causes IE to freeze until all the js has executed.

Additionally im running this on a core2 duo with 2.5g ram

[pmaslov1]

Hello,
I see there is number of things is suggested in this thread to adress this IE grid hovering issue. Unfortunately none of these things seem to bring the speed of IE close to FireFox in rendering of grid's highlight. Even in showcase example the highlight is slow in IE8. The SmartGWT version I am testing is Pro 2.3.

I have included modified showcase files so that example "Java Data Integration/Custom DataSources/Simple" would have 20 columns by 20 rows (nothing else is modified) to make problem visible.

I have used Fidler and confirm that there is no activity is going on during my hovering the grid, i.e. no images being loaded from cache.

I have also tried to use following lines which helped someone else in this thread:

userList.setWrapCells(true);
userList.setFixedRecordHeights(false);
userList.setBaseStyle("tallCell");

but it does not seem to affect the speed of highlight in this example.

Is there an internal ticket already submitted to address this highlight issue in future releases of SmartGWT?

Regards,

[Isomorphic]

It's already been addressed and we have had no new complaints for a long time.

What Showcase are you talking about? The online Showcase? If you're running the Showcase from your own system in hosted mode, that's going to be *a lot* slower than a deployed application.

[pmaslov1]

Hi, thanks for the reply, good to hear it is been addressed. I am using showcase example that comes inside "smartgwtpro-2.3.zip". The files I have attached (btw can you see them in prev. post? I dont seem to see them right now) go under following folders:

1. SimpleCustomDataSourceSample.java is in
[smartgwtpro-2.3]\samples\showcase\sr\smartgwt\sample\showcase\client\dataintegration\java\datasource

2. customDataSource_user.ds.xml is in
[smartgwtpro-2.3]\samples\showcase\war\ds

3. UserDataSource.java is in
[smartgwtpro-2.3]\samples\showcase\sr\smartgwt\sample\showcase\server\customDataSource

I am running "ant war", deploying the war file and then using IE 8 for browsing.
The hovering lag I am seeing is comparable to lag in hosted mode in a grid with 5 columns. My modification increases number of columns to 20 as this is how many our application actually has.
The PC I am using for browsing has Core 2 Duo 2,4GHz and 2GB ram.
Thank you.

[Isomorphic]

More visible columns is going to be slower (here you've set a width of 1200 to make all columns visible), but your browser and PC combination should be fast enough - the only thing we can suggest is that something might be wrong with your PC, or an add-on might be interfering with the performance of your browser, so try another machine.

[pmaslov1]

We can see thid on different PCs. May I ask you to raise an internal ticket for a future release, in order to make this highlight work as fast as it does in FireFox? Thank you.

[cventura]

is there any option for disable or turn of the row highlight in listgrid? I try:

userList.setWrapCells(true);
userList.setFixedRecordHeights(false);
userList.setBaseStyle("tallCell");

but I didn't see much diference