Using brackets but not wanting to have an array?

Discussion in 'Javascript' started by Thorben Grosser, Dec 29, 2005.

  1. Hello dear Newsgroup,

    my problem seems somehow silly, but after some googeling, I don't find
    a solution. The point is:
    I have an multiple select field to which I add values using some
    JavaScript. As I am willing to use all the values in a later PHP
    processor, I have to call these select fields like name[] and before
    submitting, I have to mark every item (JavaScript as well)
    But it seems, which is in some way logical to me, as if the javascript
    doesn't want to process variables like name[] as it probably threads it
    like an array, which it isn't (at least not in that context). Using
    name\[\] won't work either.
    What could work?

    To give a small sneak of what I am doing, check
    http://gosingen.dyndns.tv/sura/1/programm/addmovie.php but note that
    there is still a lot of mess to be cleant, the programming proably
    looks disgusting to you. It is :)

    thanks in advance
    Thorben
    Thorben Grosser, Dec 29, 2005
    #1
    1. Advertising

  2. Thorben Grosser

    RobG Guest

    Thorben Grosser wrote:
    > Hello dear Newsgroup,
    >
    > my problem seems somehow silly, but after some googeling, I don't find
    > a solution. The point is:
    > I have an multiple select field to which I add values using some
    > JavaScript. As I am willing to use all the values in a later PHP
    > processor, I have to call these select fields like name[] and before
    > submitting, I have to mark every item (JavaScript as well)
    > But it seems, which is in some way logical to me, as if the javascript
    > doesn't want to process variables like name[] as it probably threads it
    > like an array, which it isn't (at least not in that context). Using
    > name\[\] won't work either.
    > What could work?


    If you have form controls that you want to have names that include
    square brackets, they might look something like:

    <form name="blahForm" action="">
    <select name="blahSelect[]">
    ...


    Then you can access them using:

    var theSelect = document.forms['blahForm'].elements['blahSelect[]'];


    Read the FAQ on using square brackets:

    <URL:http://www.jibbering.com/faq>


    [...]


    --
    Rob
    RobG, Dec 29, 2005
    #2
    1. Advertising

  3. Thorben Grosser wrote in news:1135853254.064098.260210
    @g44g2000cwa.googlegroups.com in comp.lang.javascript:

    > Hello dear Newsgroup,
    >
    > my problem seems somehow silly, but after some googeling, I don't find
    > a solution. The point is:
    > I have an multiple select field to which I add values using some
    > JavaScript. As I am willing to use all the values in a later PHP
    > processor, I have to call these select fields like name[] and before
    > submitting, I have to mark every item (JavaScript as well)
    > But it seems, which is in some way logical to me, as if the javascript
    > doesn't want to process variables like name[] as it probably threads it
    > like an array, which it isn't (at least not in that context). Using
    > name\[\] won't work either.
    > What could work?
    >
    > To give a small sneak of what I am doing, check
    > http://gosingen.dyndns.tv/sura/1/programm/addmovie.php but note that
    > there is still a lot of mess to be cleant, the programming proably
    > looks disgusting to you. It is :)
    >


    You possibly need to use strings (as aposed to identifiers) to
    access you form elements:

    var myelememnt = document.forms['myformname'].elements['item[]'];

    The above is the most explicit way of accessig a form element, but:

    var myelememnt = document.forms['myformname']['item[]'];

    and

    var myelememnt = document.myformname['item[]'];

    should work too.

    Rob.
    --
    http://www.victim-prime.dsl.pipex.com/
    Rob Williscroft, Dec 29, 2005
    #3
  4. Works perfect, thanks to both of you :)

    have a nice time

    Thorben
    Thorben Grosser, Dec 29, 2005
    #4
  5. Thorben Grosser

    VK Guest

    Thorben Grosser wrote:
    > Hello dear Newsgroup,
    >
    > my problem seems somehow silly, but after some googeling, I don't find
    > a solution. The point is:
    > I have an multiple select field to which I add values using some
    > JavaScript. As I am willing to use all the values in a later PHP
    > processor, I have to call these select fields like name[] and before
    > submitting, I have to mark every item (JavaScript as well)
    > But it seems, which is in some way logical to me, as if the javascript
    > doesn't want to process variables like name[] as it probably threads it
    > like an array, which it isn't (at least not in that context). Using
    > name\[\] won't work either.
    > What could work?


    Any JavaScript literal can be represented upon ECMA-262 chapters which
    you should be able to spell alive, drunk or dead. At the very least
    ECMA-262 : Book Of Source is the must. So in your case:
    "[" is \u005B
    "]" is \u005D
    where both are in "Base Latin" Unicode table.

    so

    var foo\u005B\u005D = 'bar';

    is the equivalent of foo[] = 'bar' *in the way you're looking for*.
    VK, Dec 29, 2005
    #5
  6. VK wrote:
    <snip>
    > Any JavaScript literal can be represented upon ECMA-262
    > chapters which you should be able to spell alive, drunk
    > or dead. At the very least ECMA-262 : Book Of Source is
    > the must. So in your case:
    > "[" is \u005B
    > "]" is \u005D
    > where both are in "Base Latin" Unicode table.
    >
    > so
    >
    > var foo\u005B\u005D = 'bar';
    >
    > is the equivalent of foo[] = 'bar' *in the way you're
    > looking for*.


    Pure bullshit!

    <quote cite="ECMA 262, 3rd edition; Section 7.6">
    ....
    A UnicodeEscapeSequence cannot be used to put a character into an
    identifier that would otherwise be illegal. In other words, if a
    \UnicodeEscapeSequence sequence were replaced by its
    UnicodeEscapeSequence's CV, the result must still be a valid Identifier
    that has the exact same sequence of characters as the original
    Identifier.
    ....
    </quote>

    It would save everyone a great deal of time and trouble if you would do
    something about learning javascript prior to pontificating on the
    subject.

    Richard.
    Richard Cornford, Dec 29, 2005
    #6
  7. Jasen Betts wrote:
    > On 2005-12-29, VK <> wrote:

    <snip>
    >> var foo\u005B\u005D = 'bar';
    >>
    >> is the equivalent of foo[] = 'bar' *in the way you're looking for*.

    >
    > if he's looking for a syntax error it is.
    >
    > this\u005B"foo[]"\u005D = 'bar';
    >
    > works better.

    <snip>

    But it doesn't work at all well. ECMA 262 is unclear as to how that
    should be handled, but the implication of what it does have to say about
    UnicodeEscapeSequences is that the above should be a syntax error, and
    it is in IE and Opera. There is enough ambiguity in the specification to
    allow Mozilla to treat the escape sequences as square brackets and so
    operators but there are good reasons for expecting the syntax errors
    reported by other browsers.

    Javascript certainly cannot convert UnicodeEscapeSequences in its source
    code into their corresponding CVs prior to tokenisation without
    violating the specification with regard to end-of-line comments, regular
    expression and string literals (i.e. for example, /u000A may not be
    treated as a LineTerminator (ECMA 262, 3rd edition; Section 7.3) in an
    end-of-line comment or a regular expression or string literal).

    Richard.
    Richard Cornford, Dec 30, 2005
    #7
  8. Richard Cornford wrote:

    > Jasen Betts wrote:
    >> On 2005-12-29, VK <> wrote:
    >>> var foo\u005B\u005D = 'bar';
    >>>
    >>> is the equivalent of foo[] = 'bar' *in the way you're looking for*.

    >>
    >> if he's looking for a syntax error it is.
    >>
    >> this\u005B"foo[]"\u005D = 'bar';
    >>
    >> works better.

    >
    > But it doesn't work at all well. ECMA 262 is unclear as to how that
    > should be handled,


    IBTD, I think it is pretty clear about that.

    > but the implication of what it does have to say about
    > UnicodeEscapeSequences is that the above should be a syntax error,


    True. The implication of

    | Unicode escape sequences are [...] permitted in identifiers, where they
    ^^^^^^^^^^^^^^
    | contribute a single character to the identifier, as computed by the CV
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    | of the UnicodeEscapeSequence (see section 7.8.4). The \ preceding the
    | UnicodeEscapeSequence does not contribute a character to the identifier.

    is that the above should be equivalent to

    this["foo[]"] = 'bar';

    where the left hand side of the AssignmentExpression should be parsed as
    _one identifier_, at least the leading `this[' and the trailing `]' as
    two identifiers, _not_ the property accessor syntax:

    The \UnicodeEscapeSequence is allowed only in Identifiers and StringLiterals
    (the Unicode escape sequence in RegularExpressionLiterals is produced by
    `\NonTerminator', not `\UnicodeEscapeSequence'); since this is obviously
    no string literal, it must be an identifier.

    But `[' and `]' are not allowed in Identifiers, not even per evaluated
    \UnicodeEscapeSequence --

    | A UnicodeEscapeSequence cannot be used to put a character into an
    | identifier that would otherwise be illegal.

    -- (or at least `Identifier StringLiteral Identifier = StringLiteral;'
    cannot be produced by AssignmentExpression), so theoretically this is a
    SyntaxError anyway.

    However, ECMAScript allows a conforming implementation "to support program
    [...] syntax not described in this specification." ISTM that this
    provision resets all arguments about how a conforming implementation MUST
    be, as argued here, to how it CAN be, perhaps SHOULD be.

    > and it is in IE and Opera. There is enough ambiguity in the specification
    > to allow Mozilla to treat the escape sequences as square brackets and so
    > operators but there are good reasons for expecting the syntax errors
    > reported by other browsers.


    Yes, but I do not credit that to the specification's ambiguity.

    > Javascript certainly cannot convert UnicodeEscapeSequences in its
    > source code into their corresponding CVs prior to tokenisation without
    > violating the specification with regard to end-of-line comments, regular
    > expression and string literals


    Yes it can :)

    > (i.e. for example, /u000A may not be


    \u000A

    > treated as a LineTerminator (ECMA 262, 3rd edition; Section 7.3) in an
    > end-of-line comment or a regular expression or string literal).


    True, there are limitations set by ECMAScript where \UnicodeEscapeSequence
    may be used. However, by the Conformance section (e.g. ES3, section 2), a
    conforming implementation is allowed to support even that. See above.

    So the bottom line is instead that there is an ECMAScript implementation
    that supports the suggested syntax for creating property access syntax:
    JavaScript. However, as we know that there are also widely distributed
    ECMAScript implementations that do not support it (JScript, the Opera
    implementation), it is unwise to make use of it.


    PointedEars
    Thomas 'PointedEars' Lahn, Dec 30, 2005
    #8
  9. Thorben Grosser

    VK Guest

    VK wrote:
    > Any JavaScript literal can be represented upon ECMA-262 chapters which
    > you should be able to spell alive, drunk or dead. At the very least
    > ECMA-262 : Book Of Source is the must. So in your case:
    > "[" is \u005B
    > "]" is \u005D
    > where both are in "Base Latin" Unicode table.
    >
    > so
    >
    > var foo\u005B\u005D = 'bar';
    >
    > is the equivalent of foo[] = 'bar' *in the way you're looking for*.


    While writing that I was PUI (Programming Under Influence). Please take
    it into consideration while commenting and penalising.

    I guess to be a bs that an illegal literal would become legal just
    because of being Unicode-encoded. From the other side a code string
    foo[] = something; is not an illegal literal per se (as such) but only
    within the applied execution context therefore this problem could be
    solved on the execution level => so it can be solved.
    Hic!
    VK, Dec 30, 2005
    #9
  10. Thorben Grosser

    VK Guest

    Thorben Grosser wrote:
    > my problem seems somehow silly, but after some googeling, I don't find
    > a solution. The point is:
    > I have an multiple select field to which I add values using some
    > JavaScript. As I am willing to use all the values in a later PHP
    > processor


    Overall (I'm PUI again) the hole problem is artificially intoroduced by
    Zeev Suraski and Andi Gutmans by intoducing the idea of "no right
    syntacs but PHP and no gods but convenience". There are not any legal
    demands to ask "foo[]" to be just a set of char codes constituting the
    literal. And I see no legal/reasonnable reasons to find a hack for a
    OOP-compliant language to follow the PHP proprietary CGI build-up.
    VK, Dec 30, 2005
    #10
    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. Lucia
    Replies:
    5
    Views:
    322
    Roedy Green
    Nov 3, 2003
  2. Tim Apple

    Wanting to Learn

    Tim Apple, Feb 4, 2004, in forum: C Programming
    Replies:
    25
    Views:
    773
    Dik T. Winter
    Feb 7, 2004
  3. Zeljko Vrba
    Replies:
    13
    Views:
    603
  4. jt
    Replies:
    3
    Views:
    925
    Keith Thompson
    May 23, 2005
  5. Replies:
    1
    Views:
    429
    mlimber
    Dec 28, 2006
Loading...

Share This Page