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]
