Size of js files

[acarur01]

SmartClient Version: SC_SNAPSHOT-2010-12-15/PowerEdition Development Only (built 2010-12-15)

I have an inquiry regarding the javascript files that are needed for SmartClient. Some clients have expressed their concern regarding the size of the files. Through Firefox Firebug extension, we see that the combined total of SC files are around 600KB. Is there any way to further compress these files? I know the .gz files are already used which are much smaller than the actual .js files. Any suggestions would be great..maybe point out any js files we do not actually necessarily need.

We are loading the following (and caching):

ISC_History
ISC_Foundation
ISC_Containers
ISC_Grids
ISC_Forms
ISC_DataBinding
ISC_FileLoader
load_skin

Another question is, are these the same .js files that are loaded for smart-phone apps?

[Isomorphic]

You should be able to address your client's concerns by pointing out that these files are loaded once ever per user, then cached. In a typical usage profile for a business application of repeatedly visiting the application, this has an negligible performance impact.

Yes, the same files are loaded for mobile, although often a mobile interface is a simplified version and can avoid loading some modules entirely (eg Grids).

[acarur01]

That's the answer we were leaning towards - just wanted to make sure.

Another question, is there a flag that is used to determine whether to use the gzip files and not the actual javascripts sent to the browser?

[Isomorphic]

It's not a flag, it's the FileLoader servlet serving them. It will dynamically pick the .gz version for browsers capable of receiving it.

[acarur01]

Ok. Technically, we do not need to use FileLoader, am I correct?

[Isomorphic]

Sorry that should have set FileDownload servlet.

If you want to serve compressed .js reliably to all browsers, yes you need to use the FileDownload servlet. There are public instructions for setting up Apache to server compressed .js, but we have yet to see such a set of instructions that's even close to covering all the bad cases we know about.

[acarur01]

We found the file framework.properties inside isomorphic_core_rpc.jar and we changed servlet.compress to false

We need a more flexible way to do it (without repackaging the jar file).

None of this is in documentation and was found by decompiling the code. This should be documented.

[Isomorphic]

Anything in framework.properties can be overriden by setting in server.properties.

That property is not documented because there's no known reason to set it. What is your perceived reason for doing so?

[acarur01]

Where is the documentation on server.properties? How/where to package this file?

Customer is using our app behind iplanet server in proxy mode, with it's own compression turned on, which conflicts with FileDownload compression.

[Isomorphic]

server.properties is referred to pervasively in the documentation - is someone else using your support account today??

Sorry to hear about the flaw in iPlanet. The undocumented property you found is a viable workaround.

[acarur01]

Nope. Still me. Someone else from work is helping me with server-side problems (right questions to ask, etc) as it is not my forte but since I'm the one responsible for anything related to SmartClient, here I am. - Could you point me to where it is in the documentation? Search "server.properties" isn't the best way as it returns many results

[acarur01]

Nevermind. Found it in /SmartClient_Reference.html#group..iscInstall

[acarur01]

Packaging "server.properties" is not dynamic enough for us, meaning the war file has to be rebuilt and redeployed. Besides, we already had a problem with putting log4j.properties file inside war/WEB-INF/classes under weblogic (classloading wasn't finding it), so I doubt it will find this file too.

This is clearly a runtime setting. Is there any way to change this during runtime?

[Isomorphic]

You reported (and we could not verify) a problem specifically with log4j and WebLogic - loading resources from the Java classpath is a core Java capability that cannot be broken for you or nothing would work.

This undocumented setting is definitely not something we would consider a "runtime setting", sorry.