 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / JavaScript / December 2005Using brackets but not wanting to have an array?
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 > Hello dear Newsgroup, > [quoted text clipped - 9 lines] > 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> [...]  SignatureRob Thorben Grosser wrote in news:1135853254.064098.260210 @g44g2000cwa.googlegroups.com in comp.lang.javascript: > Hello dear Newsgroup, > [quoted text clipped - 14 lines] > 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. Signaturehttp://www.victim-prime.dsl.pipex.com/ Works perfect, thanks to both of you :) have a nice time Thorben > Hello dear Newsgroup, > [quoted text clipped - 9 lines] > 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*. <snip> > Any JavaScript literal can be represented upon ECMA-262 > chapters which you should be able to spell alive, drunk [quoted text clipped - 10 lines] > 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. >> Hello dear Newsgroup, >> [quoted text clipped - 22 lines] > > 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'; SignatureBye. Jasen <snip> >> var foo\u005B\u005D = 'bar'; >> [quoted text clipped - 5 lines] > > 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. >>> var foo\u005B\u005D = 'bar'; >>> [quoted text clipped - 8 lines] > 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 > 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 [quoted text clipped - 8 lines] > > 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! 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. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.