Addressing form elements using array

[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

[Lee]

Frank Stephan said:

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.

http://www.jibbering.com/faq/#FAQ4_25

[Lasse Reichstein Nielsen]

fr***********@gmx.de (Frank Stephan) writes:

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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Michael Winter]

On 7 Jan 2004 09:05:25 -0800, Frank Stephan <fr***********@gmx.de> wrote:

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: <INPUT ... name="risikenManuell[0]">
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

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[HikksNotAtHome]

In article <op**************@news-text.blueyonder.co.uk>, Michael Winter
<M.******@blueyonder.co.invalid> writes:

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(...).

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.
--
Randy

[Lasse Reichstein Nielsen]

hi************@aol.com (HikksNotAtHome) writes:

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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[HikksNotAtHome]

In article <ek**********@hotpop.com>, Lasse Reichstein Nielsen <lr*@hotpop.com>
writes:

hi************@aol.com (HikksNotAtHome) writes:

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 already knew that, I wanted to see if he knew it. And my reply seemed more
polite than a "Thats utterly false"
--
Randy

[Michael Winter]

On 07 Jan 2004 23:39:56 GMT, HikksNotAtHome <hi************@aol.com> wrote:

In article <op**************@news-text.blueyonder.co.uk>, Michael Winter
<M.******@blueyonder.co.invalid> writes:

An style comment: you should use fully-qualified references to help
prevent name collisions. That is, window.alert(...), not alert(...).

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.

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Laurent Bugnion, GalaSoft]

Hi,

Michael Winter wrote:

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
--
Laurent Bugnion, GalaSoft
Webdesign, Java, javascript: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch

[Michael Winter]

On Thu, 08 Jan 2004 08:39:07 +0100, Laurent Bugnion, GalaSoft
<galasoft-LB@bluewin_NO_SPAM.ch> wrote:

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

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Richard Cornford]

"Laurent Bugnion, GalaSoft" <galasoft-LB@bluewin_NO_SPAM.ch> wrote in
message news:bt**********@rex.ip-plus.net...
<snip>

... 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.

[Lasse Reichstein Nielsen]

Michael Winter <M.******@blueyonder.co.invalid> writes:

[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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Lasse Reichstein Nielsen]

Michael Winter <M.******@blueyonder.co.invalid> writes:

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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'