Re: Shortened autogenerated names
Re: Shortened autogenerated names
- Subject: Re: Shortened autogenerated names
- From: email@hidden
- Date: Wed, 09 Mar 2011 13:12:01 -0500
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@hidden>
To:
email@hidden
Cc:
email@hidden
Date:
03/09/2011 12:57 PM
Subject:
Re: Shortened
autogenerated names
On Mar 9, 2011, at 10:35 AM, email@hidden
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden