Re: Shortened autogenerated names
Re: Shortened autogenerated names
- Subject: Re: Shortened autogenerated names
- From: Ramsey Gurley <email@hidden>
- Date: Wed, 09 Mar 2011 10:56:44 -0700
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden