Most of us recognize that static files do not need to be served from Seaside, but it is a step that can be easily overlooked. I was recently helping someone analyze performance for a Seaside application and we found that serving the initial page made 20 Seaside requests, all but one of them for something in /files (i.e., a subclass of WAFileLibrary). In this case it was Scriptaculous, but it could be anything.
The first step to fix this is to find out which files are being served from Seaside. You can do this by looking at your web server logs or by looking at requests made by the browser (in Firefox, use Firebug). If you see SUDevelopmentLibrary being requested, then look for references to that class. Typically the class will be the argument to an #’addLibrary:’ message following a #’register:asApplicationAt:’ message. Remove the #’addLibrary:’ call and re-register your application.
Second, create operating system files containing the material previously served by Seaside. You can copy the text from the methods or you can obtain the files elsewhere. For example, to replace SUDevelopmentLibrary, go to the Scriptaculous downloads page. Note, however, that SUDevelopmentLibrary has an additional method, #’treePatchJs’, that is not included in the download. Typically these files would be placed in your web server’s /scripts directory.
Finally, add references to the static file(s) to your component. Typically this is done in #’updateRoot:’ on your component. For example:
#('prototype.js' 'scriptaculous.js' 'treePatch.js') do: [:each |
anHtmlRoot script
beJavascript;
url: '/scripts/scriptaculous/' , each;
yourself.
].
With this, we reduced by 95% the number of pages served by Seaside!
Programming Gems (on GemStone) 
3 comments
Comments feed for this article
October 5, 2011 at 7:34 am
Boris Popov
James, you could also solve this problem by making use of a CDN: http://aws.typepad.com/aws/2010/11/amazon-cloudfront-support-for-custom-origins.html, which in the context of things like complex deployment scenarios might be a simpler way of delivering static content to your users.
October 5, 2011 at 8:03 am
James Foster
Boris, If I understand correctly, you are suggesting a different location for the static files (on a unique Amazon account instead of in your web server’s file system). Of course, you could go even further and use a shared server, say Google. See http://encosia.com/3-reasons-why-you-should-let-google-host-jquery-for-you/, http://zoompf.com/blog/2010/01/should-you-use-javascript-library-cdns, and finally http://code.google.com/apis/libraries/. The concept is the same–don’t serve static files from Seaside. The only discussion is where to put the static files. Right?
October 5, 2011 at 11:19 am
Udo Schneider (@krodelin)
Another approach is to Apache with mod_rewrite and the “-f” option. So during development you simply serve all files directly from the image. On deployment you simply write all the files of all libs (you use) to a directory served by mod_rewrite. You can even configure your deployment-image to do so on each start-up. Advantage is that development and deployment “files” are always in sync. By using the -f option nobody gets hurt if you forget to write them to a dir … and because mod_rewrite (or something similar for other servers) is used anyway it doesn’t even hurt in terms of running components or configuration.