Ramsey that's a great tip! I didn't know we had such easy access to compression.
I took out a sample 20KB row of HTML data we were generating so I could experiment. If I use GREP to manually strip out whitespace and then shorten all autogenerated names to 10 characters long this dropped from 20KB -> 11KB. Here's the interesting part - If we then take the 11KB file and in the Mac's Finder zip it up the resulting file is 3.2KB. If We take the original 20KB file and zip it up the resulting file is 4.0KB - Zipping made a big difference and makes the other fiddling almost negligible. I think in our app we only extend the Ajax classes not the ER ones like Application.java. It might not be so easy for us to flip the property without first extending all of WOnder. Might be easier for us to just do it from the Apache side but the advantage of doing it in the WO app instance is that you don't have to ask the unix sysadmin to modify any server settings, just grab a new .woa and go. Thanks, -- Aaron From: Ramsey Gurley <[email protected]> To: [email protected] Cc: [email protected] Date: 03/09/2011 12:57 PM Subject: Re: Shortened autogenerated names On Mar 9, 2011, at 10:35 AM, [email protected] wrote: Hello fellow WOrriors, Have you ever looked at the names given to WO input fields such as WOTextFields? They could look like one of the following: name="0.15.37.1.1.1.0.0.3" name="0.15.37.1.5.7.1.21.1.29.270710975.3.1.1.3.8.1.0.5" They tend to get longer the more times they are nested inside of sub components. They need to be unique and it appears they follow a WOContext type of naming convention to guarantee their uniqueness. I would say this algoirthm is not random but methodical and absolutely guarantees uniqueness. I've got one page that has lots of text fields and realized that just one "row" of data is taking up 20KB of just text because of these super long names. Why couldn't one use a randomly generated unique ID that is ten characters long (or so)? There *could* be name collision but the chances would be small. Alternatively, why not invent a "context sequence" that starts at 1 and counts up throughout the Request-Response loop? That would absolutely be unique. I believe that is what they are ... a "context sequence" of sorts (^_^) Specifically, they are derived from the context().elementID(). I think how this value is created is that the first number is the contextID, followed by a '.', then each element increments the element id, and each nesting adds a '.' separator character. However, my understanding of it is likely imperfect. Has anyone heard of anybody trying to do something like this for the purpose of saving bandwidth? Perhaps even WOnder might have a cool property that we could flick on to do just this. Or... is there a very good reason why autogenerated names are built the way they are? After all, you would think someone would have optimized these to be smaller if they could. -- Aaron Ahh, but Wonder does have a cool property to fix this: ## Enable reponse compression when user agent accepts gzip # er.extensions.ERXApplication.responseCompressionEnabled = true That should bring your page size down around 85%. My typical D2W pages rarely exceed 12KB with gzip. Even with lots of inline SVG, the bandwidth savings are generally quite amazing. Large/numerous images/fonts/media will obviously eat up the bandwidth. However, if you turn on that property, I think you'll find javascript is the real bandwidth pig. Not so much WO. Ramsey
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
