"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in
message news:ct**********@chessie.cirr.com...
Lee <RE**************@cox.net> spoke thus:
Using Javascript arrays is much more efficient, both in run time and
in the amount of text to download. As far as I have been able to
tell,
the only reason that some people use hidden form fields to pass data
to a page is because they don't know any better.
As someone who helps maintain pages that make extensive use of hidden
form fields that are populated with script before the form is
submitted, I'm interested in hearing about the alternative :)
He is referring to passing data _to_ a page, not from one page to
another.
Basically, if you want dynamic server-side values to be manipulated from
client-side JavaScript you have two options:
<script type="text/javascript">
var myArray = [
<%= serverSideArray.join(',\n') %>
];
</script>
or
<!-- this could be made more efficient by putting
all array elements into a single hidden input with
a unique delimiter, then splitting the value on the
client -->
<% for (var ii = 0; ii < serverSideArray.length; ++ii) { %>
<input type="hidden"
name="element<%= ii %>"
value="<%= serverSideArray[ii] %>">
<% } %>
Both will make the -serverSideArray- values accessible from client-side
JavaScript. There are some very good reasons why you may wish to use the
second method however, one of them being that you need those values on
the _next_ page (after form submission).
Of course, if you need those values on the server on form's target, and
they originally came from the server, it might be more efficient to
simply retrieve them or calculate them again on the server when needed.
As for the original poster's question regarding efficiency. If you're
asking that question, you're using the wrong tool.
<url:
http://blogs.msdn.com/ericlippert/ar.../18/53388.aspx />
"High performance is unimportant -- as long as the page doesn't appear
to hang, its fast enough."
"Do not rely on "tips and tricks" for performance. People will tell you
"declared variables are faster than undeclared variables" and "modulus
is slower than bit shift" and all kinds of nonsense. Ignore them.
That's like mowing your lawn by going after random blades of grass with
nail scissors. You need to find the WORST thing, and fix it first.
That means measuring."
<url:
http://www.codinghorror.com/blog/archives/000185.html />
"Arguments about which method results in code that is easier to read and
easier to maintain will be gladly entertained. Arguments about speed
will not. Stop micro-optimizing and start macro-optimizing: per Lippert,
code that makes sense is code which can be analyzed and maintained, and
that makes it performant."
Please note I'm guilty of micro-optimizing myself. I often write loops
in which iteration order doesn't matter as:
var ii = length;
while (ii-- > 0) { ... }
instead of:
for (var ii = 0; ii < length; ++ii) { ... }
because the first one is "faster". Please understand, the time it takes
to _do something_ inside the loop is probably going to far outweigh any
speed gains achieved by reversing the direction of the loop. However,
I'm old and set in my ways, so I will continue to stick to this design
choice.
--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ -
http://jibbering.com/faq 
