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

Discussion in 'Javascript' started by Ted Byers, Oct 7, 2009.

  1. Ted Byers

    Ted Byers Guest

    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
    Ted Byers, Oct 7, 2009
    #1
    1. Advertising

  2. On 7 Oct, 16:26, Ted Byers <> wrote:
    > 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.
    Captain Paralytic, Oct 7, 2009
    #2
    1. Advertising

  3. Re: Quick question about using a table of text input fields within a javascrip function

    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
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Oct 7, 2009
    #3
  4. Ted Byers

    Ted Byers Guest

    On Oct 7, 11:36 am, Captain Paralytic <> wrote:
    > On 7 Oct, 16:26, Ted Byers <> wrote:
    >
    >
    >
    > > 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.


    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
    Ted Byers, Oct 7, 2009
    #4
  5. Ted Byers

    VK Guest

    > 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 :)
    VK, Oct 7, 2009
    #5
  6. Re: Quick question about using a table of text input fields within a javascrip function

    Ted Byers wrote:

    > On Oct 7, 11:36 am, Captain Paralytic <> wrote:
    >> 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.


    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
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Oct 7, 2009
    #6
  7. Ted Byers

    Ted Byers Guest

    On Oct 7, 2:30 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > Ted Byers wrote:
    > > On Oct 7, 11:36 am, Captain Paralytic <> wrote:
    > >> 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.

    >
    > 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
    Ted Byers, Oct 7, 2009
    #7
  8. Re: Quick question about using a table of text input fields within a javascrip function

    Ted Byers wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> Ted Byers wrote:
    >> > On Oct 7, 11:36 am, Captain Paralytic <> wrote:
    >> >> 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.

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


    *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
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Oct 8, 2009
    #8
  9. Ted Byers

    VK Guest

    > 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
    }
    VK, Oct 8, 2009
    #9
  10. Re: Quick question about using a table of text input fields within a javascrip function

    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
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
    Thomas 'PointedEars' Lahn, Oct 8, 2009
    #10
  11. Ted Byers

    VK Guest

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


    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.

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

    >
    > 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.
    VK, Oct 8, 2009
    #11
  12. Ted Byers

    Ted Byers Guest

    On Oct 8, 9:03 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > Ted Byers wrote:
    > > 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.)
    >

    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
    Ted Byers, Oct 8, 2009
    #12
  13. Re: Quick question about using a table of text input fields within a javascrip function

    VK wrote:

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

    >
    > 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
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Oct 8, 2009
    #13
  14. Re: Quick question about using a table of text input fields within a javascrip function

    Ted Byers wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> Ted Byers wrote:
    >> > 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.)
    >>

    > 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
    Thomas 'PointedEars' Lahn, Oct 8, 2009
    #14
  15. Ted Byers

    Ted Byers Guest

    On Oct 8, 10:14 am, VK <> wrote:
    > > 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
    Ted Byers, Oct 8, 2009
    #15
  16. Re: Quick question about using a table of text input fields within a javascrip function

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

    +=? Articles should use mainly the 7-bit ASCII character set. Articles
    in less common languages should include an abstract in English.

    --
    (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
    <URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
    <URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
    Dr J R Stockton, Oct 8, 2009
    #16
  17. Ted Byers

    VK Guest

    > > 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? ;-)


    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.
    VK, Oct 8, 2009
    #17
  18. Re: Quick question about using a table of text input fields within a javascrip function

    In comp.lang.javascript message <>,
    Thu, 8 Oct 2009 15:03:03, Thomas 'PointedEars' Lahn <>
    posted:

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

    --
    (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20; WinXP.
    Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
    PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
    My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
    Dr J R Stockton, Oct 8, 2009
    #18
  19. Re: Quick question about using a table of text input fields within a javascrip function

    VK wrote:

    >> > 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? ;-)

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

    >> BTW, an attribution line for each (or at least the first) quotation level
    >> is 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.


    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
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Oct 8, 2009
    #19
  20. Ted Byers

    GTalbot Guest

    On 8 oct, 10:14, VK <> wrote:

    > > Second question, I wrote this on the assumption that text input fields
    > > have to have unique names.


    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
    GTalbot, Oct 8, 2009
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Miguel Dias Moura
    Replies:
    1
    Views:
    449
    Jeffrey Palermo [MCP]
    Nov 25, 2004
  2. JKop
    Replies:
    11
    Views:
    879
  3. gotcha
    Replies:
    0
    Views:
    206
    gotcha
    Oct 24, 2003
  4. Abe
    Replies:
    2
    Views:
    168
  5. Replies:
    23
    Views:
    504
    Tim Streater
    Dec 18, 2013
Loading...

Share This Page