Quick question about using a table of text input fields within ajavascrip function

[Ted Byers]

Please consider this stripped down perl function that prints a
Javascript function:

sub print_javascripts {
print "<script LANGUAGE=\"Javascript\" type=\"text/javascript
\">var n = 0</script>\";
print "<script LANGUAGE=\"Javascript\" type=\"text/javascript\">
function addRow(id){
n++;\"
var str = 'item' + n;
var tbody = document.getElementById(id).getElementsByTagName
(\"tbody\")[0];
var row = document.createElement(\"tr\");
var input = document.createElement('input');
input.type = 'text';
input.name = 'str';
input.size = 50;
input.maxlength = 256;
var data = document.createElement(\"td\");
data.appendChild(input);
row.appendChild(data);
tbody.appendChild(row);
} </script>";
}

What we have here is a perl function used in a CGI script to print a
Javascript function to standard out.

As you can see, this table will look like an extensible list box,
where the user can add values by clicking on a button (of type
button) . Also, I have a little code to allow me to give each value a
unique name. Of course, the cgi script can reconstruct these names IF
it knows how many values were added.

First question: how can I create, within this function, a hidden field
that it to hold the number of new items added, in the first time it is
invoked, and update it subsequently.

Second question, I wrote this on the assumption that text input fields
have to have unique names. Is this assumption correct, or can I give
all the text input fields in this table the same name, so that in my
perl script I can get all of them as an array (the perl CGI package
allows one to get an array of all values for, e.g. options in a list
box, as an array). A listbox isn't really an option because in my
select box to allow the user to select these values after they have
been added to my DB uses the text entered to display to the user but
the value is a unique ID obtained from the DB, and there is no way to
know what ID the DB will assign to a given item.

Thanks

Ted

 

[Captain Paralytic]

Please consider this stripped down perl function that prints a
Javascript function:

sub print_javascripts {
    print "<script LANGUAGE=\"Javascript\" type=\"text/javascript
\">var n = 0</script>\";
    print "<script LANGUAGE=\"Javascript\" type=\"text/javascript\">
          function addRow(id){
             n++;\"
             var str = 'item' + n;
             var tbody = document.getElementById(id).getElementsByTagName
(\"tbody\")[0];
             var row = document.createElement(\"tr\");
             var input = document.createElement('input');
             input.type = 'text';
             input.name = 'str';
             input.size = 50;
             input.maxlength = 256;
             var data = document.createElement(\"td\");
             data.appendChild(input);
             row.appendChild(data);
             tbody.appendChild(row);
          } </script>";

}

What we have here is a perl function used in a CGI script to print a
Javascript function to standard out.

As you can see, this table will look like an extensible list box,
where the user can add values by clicking on a button (of type
button) .  Also, I have a little code to allow me to give each value a
unique name.  Of course, the cgi script can reconstruct these names IF
it knows how many values were added.

First question: how can I create, within this function, a hidden field
that it to hold the number of new items added, in the first time it is
invoked, and update it subsequently.

Second question, I wrote this on the assumption that text input fields
have to have unique names.  Is this assumption correct, or can I give
all the text input fields in this table the same name, so that in my
perl script I can get all of them as an array (the perl CGI package
allows one to get an array of all values for, e.g. options in a list
box, as an array).  A listbox isn't really an option because in my
select box to allow the user to select these values after they have
been added to my DB uses the text entered to display to the user but
the value is a unique ID obtained from the DB, and there is no way to
know what ID the DB will assign to a given item.

Thanks

Ted

The perl script is of no interest in this. It is either a javascript
question or it is not. If it is, please dump the perl code and just
post javascript and its associated javascript question.

 

[Thomas 'PointedEars' Lahn]

Ted Byers wrote in comp.lang.javascript:
^^^^^^^^^^

Please consider this stripped down perl function [...]

No.

BTW, your Perl function could use a little polish; for example,
all these escape sequences are not necessary.


PointedEars

 

[Ted Byers]

Please consider this stripped down perl function that prints a
Javascript function:

sub print_javascripts {
    print "<script LANGUAGE=\"Javascript\" type=\"text/javascript
\">var n = 0</script>\";
    print "<script LANGUAGE=\"Javascript\" type=\"text/javascript\">
          function addRow(id){
             n++;\"
             var str = 'item' + n;
             var tbody = document.getElementById(id).getElementsByTagName
(\"tbody\")[0];
             var row = document.createElement(\"tr\");
             var input = document.createElement('input');
             input.type = 'text';
             input.name = 'str';
             input.size = 50;
             input.maxlength = 256;
             var data = document.createElement(\"td\");
             data.appendChild(input);
             row.appendChild(data);
             tbody.appendChild(row);
          } </script>";

}

What we have here is a perl function used in a CGI script to print a
Javascript function to standard out.

As you can see, this table will look like an extensible list box,
where the user can add values by clicking on a button (of type
button) .  Also, I have a little code to allow me to give each value a
unique name.  Of course, the cgi script can reconstruct these names IF
it knows how many values were added.

First question: how can I create, within this function, a hidden field
that it to hold the number of new items added, in the first time it is
invoked, and update it subsequently.

Second question, I wrote this on the assumption that text input fields
have to have unique names.  Is this assumption correct, or can I give
all the text input fields in this table the same name, so that in my
perl script I can get all of them as an array (the perl CGI package
allows one to get an array of all values for, e.g. options in a list
box, as an array).  A listbox isn't really an option because in my
select box to allow the user to select these values after they have
been added to my DB uses the text entered to display to the user but
the value is a unique ID obtained from the DB, and there is no way to
know what ID the DB will assign to a given item.

Ted

The perl script is of no interest in this. It is either a javascript
question or it is not. If it is, please dump the perl code and just
post javascript and its associated javascript question.

Your response, and Thomas' response, implies that there is no place to
ask about mixed language programming. I have perl on the server side
and Javascript on the client side. I am sure I'd get a similar
response if I asked in the perl fora. This question involves both
perl and Javascript, but I asked here because it is biased toward
modifying the existing javascript function so that the perl script
knows what data the form is passing to it. If it is really
unacceptable to ask a question about mixed language programming here,
do you at least know of a forum where such questions are accepted?

The heart of this question involves the issue of writing each so they
play nicely together. Creating an extensible table with text input
fields in the table's cells is not that hard, and writing perl script
to get the value for any particular parameter is trivially easy, IF
you know the name of the field at the time you write the code.
Getting the Javascript code that handles the extensible table to work
in a way that plays nicely with the perl code that has to handle it is
not so obvious. With the existing code, new text input fields are
created, so obviously their names and number of them can not be known
at the time the code is written. In this case, the most useful answer
to modifying the javascript function has to be constructed taking into
account knowledge of how the perl will need to process the
parameters. If you don't know how to construct such an answer, there
is no point in replying.

Cheers,

Ted

 

[VK]

Your response, and Thomas' response, implies that there is no place to

ask about mixed language programming.  I have perl on the server side
and Javascript on the client side.  I am sure I'd get a similar
response if I asked in the perl fora.  This question involves both
perl and Javascript, but I asked here because it is biased toward
modifying the existing javascript function so that the perl script
knows what data the form is passing to it.  If it is really
unacceptable to ask a question about mixed language programming here,
do you at least know of a forum where such questions are accepted?

comp.lang.javascript as one of Big 8 Usenet hierarchy newsgroups has
its Charter defining the purpose of the group and the borders of
allowed topics of discussion. If posting in one of Big 8 newsgroup and
having some doubts of the kind it is a good idea to look for the group
Charter. A Usenet Big 8 Charter is not changeable for the life span of
the group and it has the absolute priority over any other group items
including FAQ, current consensus, authoritative opinion of a frequent
poster etc. Your case is very simple, as the clj Charter states and I
quote:
"... open to discussion on all aspects of JavaScript, as it relates to
HTML, Java, Perl, the World Wide Web in general, and other related
languages ..."
( http://www.faqs.org/ftp/usenet/news.announce.newgroups/comp/comp.lang.javascript
http://www.jibbering.com/faq/faq_notes/cljs_charter.html )
So yes, your question is fully suitable and welcome for this
newsgroup. I will answer it later as it's a pm mad house here right
now

 

[Thomas 'PointedEars' Lahn]

Your response, and Thomas' response, implies that there is no place to
ask about mixed language programming.

No, the point the both of were trying to make is that it does not matter how
you generate ECMAScript-conforming (or -extending) script code if you have a
problem with that script code. And it is not logical to expect from people
interested in ECMAScript implementations to imagine what the output of a
Perl script would look like, even though there may be subscribers who know
both languages. So you should post the generated code instead.

And please post properly next time: <http://jibbering.com/faq/#posting> pp.


PointedEars

 

[Ted Byers]

No, the point the both of were trying to make is that it does not matter how
you generate ECMAScript-conforming (or -extending) script code if you have a
problem with that script code.  And it is not logical to expect from people
interested in ECMAScript implementations to imagine what the output of a
Perl script would look like, even though there may be subscribers who know
both languages.  So you should post the generated code instead.

And please post properly next time: <http://jibbering.com/faq/#posting> pp.

Then both of you were wrong. Both of your responses imply reference
to a language other than javascript is inappropriate, and the charter
for this newsgroup clearly says this is wrong. According to both VK
and more importantly the charter of comp.lang.javascript (refer to
VK's reply to me here), my question/post is both appropriate and
correct.

While not everyone interested in ECMAScript will know perl, everyone
who knows perl will know exactly what that function produces, and it
is reasonable to expect there will be significant numbers of people
here who know both well enough to assist me. There is so little
"perl" in the snippet I provided, I doubt anyone had much difficulty
seeing what I was up to, and so had enough information to produce an
answer. Yes, it assumes a little more knowledge than someone who only
programs in javascript may have, but anyone who knows both javascript
and cgi programming in perl would have had no problem providing the
advice I'd requested. This is permitted by the charter for
comp.lang.javascript, which I understand is the ultimate authority on
such things.

My question was not about a problem with the javascript function
itself (that function works fine as is, if I were willing to ignore on
the server side what the user puts in the table on the client side),
but rather how to make it play nice with the perl script on the server
side.

I did read the FAQ and, once VK pointed me to it, the charter for this
newsgroup, BTW. Neither prohibit asking about interactions between
javascripts on the client side and perl scripts on the server side.
Since I was not asking for help debugging my code, I didn't think it
necessary to make it a standalone script within an HTML page (in fact
to do so would have required far more irrelevant material than the
code I posted).

Cheers,

Ted

 

[Thomas 'PointedEars' Lahn]

Then both of you were wrong.

*You* are wrong. And it is *you* who asking for assistance here, so when
told you were wrong, you should either comply and do what you are asked, or
go away. Because the people telling you are rather proficient in their
field and thus most certainly right (even if some of them are utterly wrong
at times), and any amount of arguing to the contrary is not going to get you
the answers that you seek. (It will only get you added to scorefiles and
killfiles.)

[...]
While not everyone interested in ECMAScript will know perl, everyone
who knows perl will know exactly what that function produces, and it
is reasonable to expect there will be significant numbers of people
here who know both well enough to assist me.

No, it is not. It would be reasonable that a significant number of
subscribers of comp.infosystems.www.authoring.misc, for example, know
both well enough to assist you.

My question was not about a problem with the javascript function
itself (that function works fine as is, if I were willing to ignore on
the server side what the user puts in the table on the client side),
but rather how to make it play nice with the perl script on the server
side.

So post the client-side ECMAScript script code along with the relevant
question, as you have been told. Because as much as it does not matter for
the Perl script that you are generating a client-side ECMAScript script with
it, it does not matter for the client-side ECMAScript script that you are
using Perl to generate it server-side (it would work the same with server-
side PHP, for example.)

If you are incapable of doing that, please go away (preferably to an
appropriate .misc group).

I did read the FAQ [...]

But you did not adhere to its recommendations.


PointedEars

 

[VK]

First question: how can I create, within this function, a hidden field

that it to hold the number of new items added, in the first time it is
invoked, and update it subsequently.

One way is to use closures over an inner function, but using closures
for such tasks IMHO is like invoking Satan to bring you doughnut from
the store If you don't want to use global vars then simply use
function augmentation to store any needed static (in VB sense) data.

Second question, I wrote this on the assumption that text input fields
have to have unique names. Is this assumption correct, or can I give
all the text input fields in this table the same name, so that in my
perl script I can get all of them as an array (the perl CGI package
allows one to get an array of all values for, e.g. options in a list
box, as an array).

No, you don't have to NAME input differently, this applies to ID only.
At the same time to make your code more portable it maybe worth to use
different names in "BaseName[index]" format and to form array server-
side on submit. This way you JavaScript will be PHP friendly as well.
Just a suggestion.

Also I would highly suggest to use table-specific DOM methods rather
than generic ones.

The rest of changes are important/non-important depending on what
legacy environments you want to support. Say
inputElement.type = "someType"
will lead to security exception on IE6, one needs to use IE(5,6)-
specific twisted-around way to assign input types. Because
createElement('INPUT') creates by default type="text" and because this
is the type you need, we can make the code IE6-compatible by simply
removing this unnecessary assignment.

----------------------------------------

#!/usr/bin/perl

$tableID = 'Interface';

print <<EOT;
<DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>Test</title>
EOT

&print_javascripts('item');

print <<EOT;
</head>
<body>
<form action="" method="GET">
<table id="$tableID">
<thead>
<tr>
<th>Test</th>
</tr>
</thead>
<tfoot>
<tr>
<td><input type="button" value="Add row"
onclick="addRow(\'$tableID\')"></td>
</tr>
<tr>
<td><input type="submit"></td>
</tr>
</tfoot>
<tbody></tbody>
</table>
</form>
EOT
exit(0);

sub print_javascripts {
print <<EOT;
<script type="text/javascript">
function addRow(id) {
var tbody = document.
getElementById(id).tBodies[0];

var input = document.createElement('INPUT');
var name = \'$_[0]\';
# PHP-friendly variant:
# var name = \'$_[0]\' +
# '[' + arguments.callee.n + ']';
input.name = name;
input.size = 50;
input.maxlength = 255;

((tbody.
insertRow(-1)).
insertCell(-1)).
appendChild(input);

arguments.callee.n++;
}
addRow.n = 0;
</script>
EOT
}

 

[Thomas 'PointedEars' Lahn]

VK wrote:

An attribution line is missing here.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

[...]

Second question, I wrote this on the assumption that text input fields
have to have unique names. Is this assumption correct, or can I give
all the text input fields in this table the same name, so that in my
perl script I can get all of them as an array (the perl CGI package
allows one to get an array of all values for, e.g. options in a list
box, as an array).

No, you don't have to NAME input differently, this applies to ID only.
At the same time to make your code more portable it maybe worth to use
different names in "BaseName[index]" format and to form array server-
side on submit. This way you JavaScript will be PHP friendly as well.
Just a suggestion.

Also I would highly suggest to use table-specific DOM methods rather
than generic ones.

The rest of changes are important/non-important depending on what
legacy environments you want to support. Say
inputElement.type = "someType"
will lead to security exception on IE6,

It does only lead to such an exception there if a `type' attribute or
property has already been specified.

one needs to use IE(5,6)- specific twisted-around way to assign input
types.

No, one does not.

Because createElement('INPUT') creates by default type="text"

The reason behind this, is of course, that the default value of the `type'
attribute of INPUT/input elements is "text".

and because this is the type you need, we can make the code IE6-compatible
by simply removing this unnecessary assignment.
True.

----------------------------------------

#!/usr/bin/perl

$tableID = 'Interface';
[...]

Yuck.


PointedEars

 

[VK]

The rest of changes are important/non-important depending on what

It does only lead to such an exception there if a `type' attribute or
property has already been specified.

In IE(5,6)-specific way as say
document.createElement('<INPUT TYPE="BUTTON"')
which is obviously very far from the createElement method syntax.

var b = document.createElement('INPUT');
b.type = 'BUTTON'; // etc.

leads to the run-time error.

No, one does not.

See explanation above. I have no intention to spell all practical
programming basics in this post as being OT. Just check it yourself,
or simply accept it, or do not check and do not accept, or check it to
be true but do not accept - it is fully your decision.

 

[Ted Byers]

*You* are wrong.  And it is *you* who asking for assistance here, so when
told you were wrong, you should either comply and do what you are asked, or
go away.  Because the people telling you are rather proficient in their
field and thus most certainly right (even if some of them are utterly wrong
at times), and any amount of arguing to the contrary is not going to get you
the answers that you seek.  (It will only get you added to scorefiles and
killfiles.)

Thomas,

Your claim that anyone answering is right even when they're wrong is
shear folly. Yes, my question is directed to people who are experts
in javascript as it interacts with CGI programs. If you had the
expertise you claim, you would have had no trouble knowing exactly
what I was up to and would have been able to provide a concise answer,
perhaps with an illustrative code block (but more likely not: with the
options I can conceive of at present, a short paragraph or two of
explanation of possible options would likely suffice).

But, have you bothered to read either VK's reply to me or even your
own charter?

I will quote VK here, as he quotes the charter correctly (as I
confirmed by examining the documents he provided links to), just in
case you can't be bothered doing your homework.

comp.lang.javascript as one of Big 8 Usenet hierarchy newsgroups has
its Charter defining the purpose of the group and the borders of
allowed topics of discussion. If posting in one of Big 8 newsgroup and
having some doubts of the kind it is a good idea to look for the group
Charter. A Usenet Big 8 Charter is not changeable for the life span of
the group and it has the absolute priority over any other group items
including FAQ, current consensus, authoritative opinion of a frequent
poster etc. Your case is very simple, as the clj Charter states and I
quote:
"... open to discussion on all aspects of JavaScript, as it relates to
HTML, Java, Perl, the World Wide Web in general, and other related
languages ..."
( http://www.faqs.org/ftp/usenet/news.announce.newgroups/comp/comp.lang....
http://www.jibbering.com/faq/faq_notes/cljs_charter.html )
So yes, your question is fully suitable and welcome for this newsgroup.

As I see it, no one would lose anything if you added them to your kill
file. I have read a lot of posts in this forum over the past few days
and I have yet to find one post from you where you provided a
constructive answer while I have found plenty where you berate people
who ask questions you apparently don't know the answer to. I won't
say you haven't provided any useful, constructive relies to questions,
only that based on what I have read so far such posts are greatly out
numbered by posts where you only berate people who ask questions that,
for whatever reason, you find offensive.

[...]
While not everyone interested in ECMAScript will know perl, everyone
who knows perl will know exactly what that function produces, and it
is reasonable to expect there will be significant numbers of people
here who know both well enough to assist me.

No, it is not.  It would be reasonable that a significant number of
subscribers of comp.infosystems.www.authoring.misc, for example, know
both well enough to assist you.

Of course it is. Your charter explicitly says that everything related
to javascript including how it interacts with HTML, Java, Perl, and
other related languages (presumably any language used for CGI
programming). It is not possible to talk about interactions between
javascript and those languages used for CGI programming if no one in
the forum knows those other languages. Don't take my word for it,
read the charter for yourself.

My question was not about a problem with the javascript function
itself (that function works fine as is, if I were willing to ignore on
the server side what the user puts in the table on the client side),
but rather how to make it play nice with the perl script on the server
side.

So post the client-side ECMAScript script code along with the relevant
question, as you have been told.  Because as much as it does not matterfor
the Perl script that you are generating a client-side ECMAScript script with
it, it does not matter for the client-side ECMAScript script that you are
using Perl to generate it server-side (it would work the same with server-
side PHP, for example.)

If you are incapable of doing that, please go away (preferably to an
appropriate .misc group).

I did read the FAQ [...]

But you did not adhere to its recommendations.

To be more precise, I did not comply with your misinterpretation of
the FAQ's recommendations!

I did, however, comply with both the FAQ and the charter for this
group. Regardless of how opinionated you may be, or how firmly you
believe what you are saying, the charter for this group takes
precedence. If you can't accept that, then go ahead and add me to
your own kill file, or go through whatever process is required to
change the charter for this group. You have managed to convince me
that you lack the expertise I seek anyway. Therefore, I will lose
nothing by being added to your kill file. I am certain that folk like
VK, and others from this forum that have helped me in the past, will
not follow your example. And once I have gained the kind of expertise
in javascript that I have earned in the other languages I have used
over the decades, I will be answering many of those questions you so
despise. I am not the sort of man who can not be intimidated by guys
like you, and unlike you I am well aware that there are kids just
starting out that will both make the kinds of mistakes you routinely
berate people for asking and who can be intimidated. Therefore, I am
tolerant of human fallibility even when they have made the sort of
mistake you've been falsely accusing me of making.

If I was asking for help debugging a script, I'd be providing complete
html, that has been passed through a couple validators I have found,
that included everything required to just load it into your favourite
browser to see the script in action. But I did not ask for debugging
help in this instance, so providing such a page is both unnecessary
and irrelevant. The code I posted was intended only as very concise
documentation of how I made a table of input fields that could be
extended. In those few cases where I have needed debugging help, I
have posted complete, stripped down, code. Apparently you don't
understand the difference between providing code as documentation of
what is being done and providing code for the purpose of seeking
debugging assistance.

You've almost gained an understanding of the question. It is true
that someone using PHP on the server side will have to deal with the
same issue. The same is true for those using C/C++ or java for their
CGI program. The core of the issue is how the cgi script knows what
data is being sent to it by a client side form that includes a table
of text input fields. My question, then, would be of general interest
to anyone who needs to get his javascript to play nicely with his CGI
program, regardless of what language that CGI program is in (although
if the language used for the CGI program lacks features available in
Perl, a solution that is done on the server may be a bit more
challenging). It is, of course, of no interest to anyone who uses
javascript only for tasks that involve only the client. While I know
C/C++, Java, Perl and PHP, I used, and referred to, perl because it is
the only language I use for CGI programming. But anyone who provided
a solution in terms of any of these other languages would be as
helpful to me as one who referred to CGI programming in perl. While I
have some ideas I will be testing today for options on the server side
in my perl code, I think an option, if one exists, involving
javascript on the client side may well serve to simplify the server
side code regardless of the language used, and a client side solution
may well make more efficient use of processing resources.

Cheers,

Ted

 

[Thomas 'PointedEars' Lahn]

In IE(5,6)-specific way as say
document.createElement('<INPUT TYPE="BUTTON"')
which is obviously very far from the createElement method syntax.

But, as I pointed out, that is unnecessary.

var b = document.createElement('INPUT');
b.type = 'BUTTON'; // etc.

leads to the run-time error.

Not in my IE 5.5 or 6.0. What am I doing wrong? ;-)

BTW, an attribution line for each (or at least the first) quotation level is
still missing from your postings.


PointedEars

 

[Thomas 'PointedEars' Lahn]

*You* are wrong. And it is *you* who asking for assistance here, so when
told you were wrong, you should either comply and do what you are asked,
or go away. Because the people telling you are rather proficient in
their field and thus most certainly right (even if some of them are
utterly wrong at times), and any amount of arguing to the contrary is not
going to get you the answers that you seek. (It will only get you added
to scorefiles and killfiles.)

Thomas,

Your claim that anyone answering is right even when they're wrong is
shear folly. [...]

I can live with that assessment. The question is: can you?

*PLONK*


PointedEars

 

[Ted Byers]

First question: how can I create, within this function, a hidden field
that it to hold the number of new items added, in the first time it is
invoked, and update it subsequently.

One way is to use closures over an inner function, but using closures
for such tasks IMHO is like invoking Satan to bring you doughnut from
the store If you don't want to use global vars then simply use
function augmentation to store any needed static (in VB sense) data.

Second question, I wrote this on the assumption that text input fields
have to have unique names.  Is this assumption correct, or can I give
all the text input fields in this table the same name, so that in my
perl script I can get all of them as an array (the perl CGI package
allows one to get an array of all values for, e.g. options in a list
box, as an array).

No, you don't have to NAME input differently, this applies to ID only.
At the same time to make your code more portable it maybe worth to use
different names in "BaseName[index]" format and to form array server-
side on submit. This way you JavaScript will be PHP friendly as well.
Just a suggestion.

Also I would highly suggest to use table-specific DOM methods rather
than generic ones.

The rest of changes are important/non-important depending on what
legacy environments you want to support. Say
 inputElement.type = "someType"
will lead to security exception on IE6, one needs to use IE(5,6)-
specific twisted-around way to assign input types. Because
createElement('INPUT') creates by default type="text" and because this
is the type you need, we can make the code IE6-compatible by simply
removing this unnecessary assignment.

----------------------------------------

#!/usr/bin/perl

$tableID = 'Interface';

print <<EOT;
<DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type"
 content="text/html; charset=iso-8859-1">
<title>Test</title>
EOT

&print_javascripts('item');

print <<EOT;
</head>
<body>
<form action="" method="GET">
<table id="$tableID">
 <thead>
  <tr>
   <th>Test</th>
  </tr>
 </thead>
 <tfoot>
  <tr>
   <td><input type="button" value="Add row"
        onclick="addRow(\'$tableID\')"></td>
  </tr>
  <tr>
   <td><input type="submit"></td>
  </tr>
 </tfoot>
 <tbody></tbody>
</table>
</form>
EOT
exit(0);

sub print_javascripts {
 print <<EOT;
<script type="text/javascript">
 function addRow(id) {
  var tbody = document.
      getElementById(id).tBodies[0];

  var input = document.createElement('INPUT');
  var name = \'$_[0]\';
# PHP-friendly variant:
#  var name = \'$_[0]\' +
#             '[' + arguments.callee.n + ']';
  input.name = name;
  input.size = 50;
  input.maxlength = 255;

  ((tbody.
     insertRow(-1)).
     insertCell(-1)).
     appendChild(input);

  arguments.callee.n++;
 }
 addRow.n = 0;
</script>
EOT

}

Thanks VK,

I appreciate this. While I have been using the other languages I know
for a long time, I just started adding Javascript to the suite of
languages I use. I did not know arrays were an option in Javascript.

I tend to avoid closures whenever I can, in the other languages I
know.

I don't have to worry about supporting PHP because, although I know it
at a basic level, I prefer perl and I am writing all the code (and the
person most likely to take it over knows perl but not php). But I
will try to make it php friendly, just to develop habits that make my
code friendly to as many server side CGI-useful languages as I can
should I find myself working with a team that opts for php or some
other language instead. I will, though, have to worry about the
browser as I have no influence on that. The end users will be using
school or home computers, and there is no telling how old their
machines/software are.

I appreciate your efforts.

Thank you

Ted

 

[Dr J R Stockton]

In comp.lang.javascript message <449c2037-e99a-4a4f-96d0-c705f9273933@q1
4g2000vbi.googlegroups.com>, Wed, 7 Oct 2009 11:05:02, VK

comp.lang.javascript as one of Big 8 Usenet hierarchy newsgroups has
its Charter defining the purpose of the group and the borders of
allowed topics of discussion. If posting in one of Big 8 newsgroup and
having some doubts of the kind it is a good idea to look for the group
Charter. A Usenet Big 8 Charter is not changeable for the life span of
the group and it has the absolute priority over any other group items
including FAQ, current consensus, authoritative opinion of a frequent
poster etc. Your case is very simple, as the clj Charter states and I
quote:
"... open to discussion on all aspects of JavaScript, as it relates to
HTML, Java, Perl, the World Wide Web in general, and other related
languages ..."
( http://www.faqs.org/ftp/usenet/news.announce.newgroups/comp/comp.lang.javascript
http://www.jibbering.com/faq/faq_notes/cljs_charter.html )
So yes, your question is fully suitable and welcome for this
newsgroup. I will answer it later as it's a pm mad house here right
now

The Charter needs correcting, since comp.lang.java.* should be
recommended rather than just comp.lang.java. And it should never have
contained "proposed". And it appears not to include WSH JScript & other
non-Web applications.

<FAQENTRY> Section 1.2 could include, after the link to the actual
charter, a new final paragraph showing the Charter explicitly as we
would like it to be after any revision. Maybe :-

Newsgroup <is for discussion of all aspects
of JavaScript, both as it relates to HTML, Java, Perl, the World Wide
Web in general, and other languages and as implemented in other systems.
The scope of discussion excludes matters which are *solely* related to
the language Java, which is discussed in news hierarchy
<
+=? Articles should use mainly the 7-bit ASCII character set. Articles
in less common languages should include an abstract in English.

 

[VK]

var b = document.createElement('INPUT');

Not in my IE 5.5 or 6.0.  What am I doing wrong? ;-)

Nothing especially wrong, just IE6 has a majority of security fixes,
some of which are not directly attributed as IE-fix but coming as
Windows XP fixes. Say the only real IE6 I left for testing is
6.0.2900.2180 / Windows XP SP2 and it gives "Command not supported"
exception for

var elm = document.createElement('INPUT');
elm.type = 'RADIO'; // exception here

var elm = document.createElement('BUTTON');
elm.type = 'BUTTON'; // exception here

Before it was OK with radio but nasty with "FILE", before I do not
remember exactly. MS had to issue fire alarm fixes for IE6 for years,
sometimes an important behavior difference depends on the lesser-
lesser-minor version. It is easier and more reliable to use a
"cumulative rule":
if IE6 and not default TYPE
then use only IE-specific createElement syntax.

BTW, an attribution line for each (or at least the first) quotation levelis
still missing from your postings.

Right, but I am not arguing with a specific opinion out of several
opinions expressed on the subject within the same thread. In this case
I do not add the attribution line as it doesn't bear any practical
importance.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

*You* are wrong. And it is *you* who asking for assistance here, so when
told you were wrong, you should either comply and do what you are asked, or
go away.

By analogy with that argument :

Since you have repeatedly been told in various terms by quite a number
of people here that you are an ill-mannered, obnoxious, arrogant,
offensive, etc. squit who needs to learn to behave like a civilised
human being, you should by now have either complied and done what you
were asked, or have gone away.

There are plenty of nicer people here who can answer, in less haste and
with more care, the questions that you reply to.

 

[Thomas 'PointedEars' Lahn]

^^^
Nothing especially wrong,

You need to learn to recognize when a question is asked seriously and when
not. I have even given you a hint.

just IE6 has a majority of security fixes,
some of which are not directly attributed as IE-fix but coming as
Windows XP fixes. Say the only real IE6 I left for testing is
6.0.2900.2180 / Windows XP SP2 and it gives "Command not supported"
exception for

var elm = document.createElement('INPUT');
elm.type = 'RADIO'; // exception here

var elm = document.createElement('BUTTON');
elm.type = 'BUTTON'; // exception here
[...]

IOW, triggering an error with the standards-compliant approach is only a
problem in obviously obsolete versions that pose a security risk, versions
that nobody, but *nobody*, should still be running. By which it can be
concluded that the standards-compliant approach is safe indeed, and that
your statement before ranges from being irrelevant to wrong.

Right, but I am not arguing with a specific opinion out of several
opinions expressed on the subject within the same thread. In this case
I do not add the attribution line as it doesn't bear any practical
importance.

The attribution line is customary on Usenet, not least because it is
regarded a simple courtesy to those who you quoted in your postings. The
FAQ of this newsgroup also strongly recommends it. So following that custom
would be wise, unless you do not want to be taken seriously (and there are
times when I got the impression that this is all a great joke to you.)


PointedEars

 

[GTalbot]

Folks, please research a bit before posting about a rather well known
issue.

http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/DynamicallyInsertedFormControlsIE7bug.html

{
Internet Explorer 8 and later can set the NAME attribute at run time
on elements dynamically created with the createElement method. To
create an element with a NAME attribute in earlier versions of
Internet Explorer, include the attribute and its value when using the
createElement method.
}
http://msdn.microsoft.com/en-us/library/ms534184(VS.85).aspx

Semicolon's "Setting the 'name' attribute in Internet Explorer" by
Bennett McElwee

http://www.thunderguy.com/semicolon/2005/05/23/setting-the-name-attribute-in-internet-explorer/

  var input = document.createElement('INPUT');
  var name = \'$_[0]\';
# PHP-friendly variant:
#  var name = \'$_[0]\' +
#             '[' + arguments.callee.n + ']';
  input.name = name;

Gérard