Using brackets but not wanting to have an array?

[Thorben Grosser]

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

[RobG]

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="blahSelec t[]">
...
Then you can access them using:

var theSelect = document.forms['blahForm'].elements['blahSelect[]'];
Read the FAQ on using square brackets:

<URL:http://www.jibbering.c om/faq>
[...]
--
Rob

[Rob Williscroft]

Thorben Grosser wrote in news:1135853254 .064098.260210
@g44g2000cwa.go oglegroups.com in comp.lang.javas cript:

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.myform name['item[]'];

should work too.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Thorben Grosser]

Works perfect, thanks to both of you :)

have a nice time

Thorben

[VK]

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

[Richard Cornford]

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 UnicodeEscapeSe quence cannot be used to put a character into an
identifier that would otherwise be illegal. In other words, if a
\UnicodeEscapeS equence sequence were replaced by its
UnicodeEscapeSe quence'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.

[Jasen Betts]

On 2005-12-29, VK <sc**********@y ahoo.com> wrote:

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

if he's looking for a syntax error it is.

this\u005B"foo[]"\u005D = 'bar';

works better. but it's only another way of writing

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

--

Bye.
Jasen

[Richard Cornford]

Jasen Betts wrote:

On 2005-12-29, VK <sc**********@y ahoo.com> 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
UnicodeEscapeSe quences 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 UnicodeEscapeSe quences 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.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

Jasen Betts wrote:

On 2005-12-29, VK <sc**********@y ahoo.com> 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
UnicodeEscapeSe quences 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 UnicodeEscapeSe quence (see section 7.8.4). The \ preceding the
| UnicodeEscapeSe quence 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 AssignmentExpre ssion should be parsed as
_one identifier_, at least the leading `this[' and the trailing `]' as
two identifiers, _not_ the property accessor syntax:

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

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

| A UnicodeEscapeSe quence 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 AssignmentExpre ssion), 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 UnicodeEscapeSe quences 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 \UnicodeEscapeS equence
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

[VK]

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!