Cache styles on smart client with application.overrideStyle

Classic Servoy
1

Case #207702.

Servoy does not cache styles on smart client when using application.overrideStyle().

We’re not exactly sure the order of events, but the following seems to make sense:

1- We issue an application.overrideStyle(‘FRAMEWORKS’,‘fw_MAC_leopard’) command for whatever OS the client is running on at startup.
2- Servoy remembers that override
3- When a new form is loaded, Servoy overrides the style…but
4- It does this on the client

So everytime a new form is navigated to, the whole style file is pushed down to the client afresh (it is NOT cached at the client like a browser will do).

Our style average about 20k. So for each form viewed, that is 20k over the wire. Throw in a typical screen like a CRM with 3-5 forms in tab panels and we’re at 100k. This produces a significant data transfer spike the first time the screen is loaded.

2

We are already aware of that styles are not cached on the client and we are looking into it.

But the thing you say is that the same style is loaded over and over again for 1 solution run?
That should then really be looked at more closely.

Can you make a case for this?

3

The case number is above.

And yes, every form loads the style sheet when application.overrideStyle() is used. So a screen that has many forms included via tab panels or split beans or whatever can really spike the amount of data transferred when that screen first loads.

We have optimized our frameworks to the (n)th degree for WAN speed. We’re at the point where a very complex solution is as responsive as the Servoy demo CRM. Except for this one bottle-neck, which is fairly significant.

4

Main point I left out:

This behavior only happens when a screen is first loaded. After that, things work as expected.

5

yes i located the problem and i am now working on it
We will try to cache the styles completely on the client even after reopening a client.

Besides those optimalizations i think we have a big suprise for you in 4.1.3 …

6

Too freaking cool. Seriously, thanks!

7

I support David on this request, it is very significant and on some solutions it slows down the client to a point where it is unusable :(

Thanks for looking at it.

  • Can’t wait for 4.1.3!