Addressing form elements using array

F

Frank Stephan

Hi,

im using Struts with nested tags for form validation.
So I end up with form elements named like this

risikenManuell[0].praemieNeu
risikenManuell[1].praemieNeu
....

I would like to do a calculation on the input values
using javascript but I don't know how to
address the fields.

With alert(document.vertragEditForm.risikenManuell[0].praemieNeu);
I get the error, that this element is null or not an object.

Is there a way to do it.

TIA
Frank
 
M

Michael Winter

Hi,

im using Struts with nested tags for form validation.
So I end up with form elements named like this

risikenManuell[0].praemieNeu
risikenManuell[1].praemieNeu
...

You mean like: said:
I would like to do a calculation on the input values
using javascript but I don't know how to
address the fields.

With alert(document.vertragEditForm.risikenManuell[0].praemieNeu);

An style comment: you should use fully-qualified references to help
prevent name collisions. That is, window.alert(...), not alert(...).
I get the error, that this element is null or not an object.

The problem with your line above is that brackets ([ ]) are operators,
used to subscript arrays. The JavaScript engine will interpret the
risikenManuell[0] above as 'evaluate the first element of the array,
risikenManuell'. To get around this, and other cross-browser problems, use
the collections syntax:

document.forms['form_name'].elements['control_name'].method_or_property

For example,

document.forms['vertragEditForm'].elements['risikenManuell[0]'].praemieNeu

Mike
 
L

Lasse Reichstein Nielsen

So I end up with form elements named like this

risikenManuell[0].praemieNeu ....
With alert(document.vertragEditForm.risikenManuell[0].praemieNeu);
I get the error, that this element is null or not an object.

Is there a way to do it.

Yes, and it's even in the FAQ:
<URL:http://jibbering.com/faq/#FAQ4_25>
In your case:
document.forms['vertragEditForm'].elements['riskenManuell[0].praemieNeu']

/L
 
L

Lasse Reichstein Nielsen

Is there a browser that will alert when using window.alert(...) but
*not alert* when using alert(...) ??

Only if you have created another variable in scope with the name
"alert". However, symmetrically, "window.alert" will fail if you have
another variable called "window" in scope.

I don't see any argument for writing "window." in front of global
variables. I do it in *one* case: in front of "window.open" mainly for
readability. It clearly distinguishes it from "document.open".

Otherwise I just write "alert", just as I write "parseFloat", "Object"
and "Array" ... and "window". There is no difference between these,
they are all just global variables (i.e., properties of the global
object).

/L
 
M

Michael Winter

Is there a browser that will alert when using window.alert(...) but *not
alert*
when using alert(...) ??

If there isn't, then it seems superfluous.

Read what I said again: "...to help prevent name collisions." I said
nothing about browsers not accepting alert(...). Furthermore, I said that
it was a style comment - therefore is was subjective, optional, and had no
direct relationship to the solution.

I take Mr Nielsen's point about the possibility of failure when a
variable, window, is present in the same scope. However, I would think
that no-one would create such a variable when accessing a window property
or method. Especially when there would be no need to call it 'window', and
a better, more descriptive name probably exists* (newWindow, popupWindow,
helpWindow, etc.)

Mike


* The first two examples would only be 'better' names if used soon after
the creation of a window and only for a short time.
 
L

Laurent Bugnion, GalaSoft

Hi,

Michael said:
Read what I said again: "...to help prevent name collisions." I said
nothing about browsers not accepting alert(...). Furthermore, I said
that it was a style comment - therefore is was subjective, optional, and
had no direct relationship to the solution.

I take Mr Nielsen's point about the possibility of failure when a
variable, window, is present in the same scope. However, I would think
that no-one would create such a variable when accessing a window
property or method. Especially when there would be no need to call it
'window', and a better, more descriptive name probably exists*
(newWindow, popupWindow, helpWindow, etc.)

Mike


* The first two examples would only be 'better' names if used soon after
the creation of a window and only for a short time.

Which brings us to the next question: Who would be silly enough to use
"alert" as a global variable, resp. function name? The risk of name
collision exists in both cases. Concretely, there is nothing which
speaks in favour of using window.alert() instead of alert(), and there
is at least one argument against it: More code is sent to the client
which increases the file size ;-)

Laurent
 
M

Michael Winter

Which brings us to the next question: Who would be silly enough to use
"alert" as a global variable, resp. function name? The risk of name
collision exists in both cases. Concretely, there is nothing which
speaks in favour of using window.alert() instead of alert(), and there
is at least one argument against it: More code is sent to the client
which increases the file size ;-)

I would argue in favour of consistency. One would qualify references to
methods and properties, such as open() and close(), to distinguish between
the window and document members. Why not do it all the time? Why make
special cases?

Anyway, I already said that this was a matter of personal preference, so
let's not get hung-up on it, shall we?

Mike
 
R

Richard Cornford

message
... and there is at least one argument against it:
More code is sent to the client which increases the
file size ;-)

To which it could be added that the qualified reference will take
fractionally longer to resolve.

There is a context in which it probably is advisable to (at leas
sometimes) provide more qualified references, and it is because of the
scope considerations that Lasse mentioned. The strings provided as
values of event handling attributes are used as the function bodies of
internally generated function objects assigned as methods of the
corresponding HTML elements. And some browsers provide those functions
with custom scope handling features that effectively add various objects
from the DOM to the scope chain of the function. One object that is
commonly added to such a scope chain is the - document - so a call to -
open() - may be resolved as - document.open - or as - window.open -
depending on whether the browser places the - document - in the scope
chain or not.

Another context where qualifying a global property with - window - (or
some similar property that refers to the global object) is when
performing type-converting test on global properties:-

if(location){
...
}

would usually produce an error if - location - was undefined, while:-

if(window.location){
...
}

- will happily type-convert to true/false regardless. Though:-

if(typeof location != 'undefined'){
...
}

- does not produce an error even if - location - is undefined (but it is
a slower operation).

I don't think that I would ever bother qualifying - alert("xxx"); - (but
alert is more of a debugging tool anyway so there is maybe no need to
worry about the validity of the assumption that it exists in the
environment).

Richard.
 
L

Lasse Reichstein Nielsen

[variable called "window"]
However, I would think that no-one would create such a variable when
accessing a window property or method.

While I would probably not make one, thinking about it I believe that
I would be more likely to make a variable called "window" than one
called "alert". I often need to name the return value of window.open,
and while "newWindow" is better, it's also longer. But that's probably
why it's usually just "w".
/L
 
L

Lasse Reichstein Nielsen

Michael Winter said:
I would argue in favour of consistency. One would qualify references
to methods and properties, such as open() and close(), to distinguish
between the window and document members. Why not do it all the time?
Why make special cases?

Are you planning on writing:
window.eval, window.parseFloat, new window.Object, new window.Function,
window.document.body, and window.document.getElementById? Or event
window.window :)

And why "window", why not "self", which is a reference to the same object?
Anyway, I already said that this was a matter of personal preference,
so let's not get hung-up on it, shall we?

Arh, you no phun! :p
/L
 
L

Laurent Bugnion, GalaSoft

Hi,
[variable called "window"]
However, I would think that no-one would create such a variable when
accessing a window property or method.


While I would probably not make one, thinking about it I believe that
I would be more likely to make a variable called "window" than one
called "alert". I often need to name the return value of window.open,
and while "newWindow" is better, it's also longer. But that's probably
why it's usually just "w".
/L

Ooh, bad practice ;-)

Laurent
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top