On 6/25/06, James Margaris <[EMAIL PROTECTED]> wrote:
About the Rhino compression working on windows/unix/etc. In the Dojo build process it looks like the only javascript file they compress is the main dojo.js, and any other files you pull in separately and uncompressed.
I think perhaps the piece you're missing is that the build process *creates* dojo.js before it compresses it. It is created according to the profile. Thus, it contains all of the packages that you said, in the profile, that you wanted. So, for example, if you build with the 'kitchen sink' profile, you will end up with just about all of Dojo in one compressed dojo.js file. The purpose of the profile is to build that one js file containing everything you expect to need in your application (or everything you care to download up front - more on that in a moment). This is by far the most efficient way to start up your app, because it requires only one round trip to the server to get all of that JavaScript code, instead of making a separate request for each piece. (I've seen other frameworks make all those requests individually, and it *kills* the app's startup performance *completely*, whether or not those files are compressed.) However, using a profile does not limit your app to using only what is defined in that profile, since Dojo will still dynamically pull additional pieces from the server on an as-needed basis. So even if you simply use the 'minimal' profile, you can still use every last widget that Dojo has. It's just that those additional pieces will be downloaded one at a time, making potentially unnecessary round trips to the server. I do understand what you're saying about the files not bundled into dojo.jsnot being compressed, and I'm not sure why that is. It'd be worth a question on the Dojo list to find out, though. On the other hand, they're better built into the profile anyway, if you're going to need them. ;-) I wrote a small java program that compresses every xap file. However I ran
into problems in that if I had the jar in the classpath and called it for each file the state would not reset between files and each file would include all the previous ones.
It's not the classpath, it's the JVM, and the problem is caused by the way Rhino works. The way to work around it in Ant is just to use fork='true' for the <java> task that runs ShrinkSafe. -- Martin Cooper To get around this I used Runtime.exec() so that each call the the jar for
each file to compress was distinct and would reset. That is why my uncertainty comes in, since Runtime.exec() relies on a command-line string that might be different on different OSs. --- I'll convert a couple of files to a package system this week so people can see what it looks like. One file. xap.util.Character, already is a part of a package, I did that a while ago as a test. James Margaris
