separation

[Dave]

Gang,

I'm trying to split the text in a select object's list but can't
seem to find the right combination. I'm using FF (haven't tested with
IE) and will give some code below. Anyone that can help with this, I
would greatly be appreciated.

The select object's list is created (successfully) with a 'for' loop
in php using the following code:

print "<option value='$val'>".$name[0]."&nbsp;".$name[1]."&nbsp;".$name
[2]."&nbsp;".$name[3]."</option>\n";

As the above code denotes, the $val variable contains a certain value
that can't be altered and the display (aka text) is a person's name
separated into first, middle, last, and suffix fields. I can tell
that the &nbsp; are being used correctly because where names entered
that don't have a middle name, there is an obviously larger space
between their first and last. The javascript code I'm using is as
follows:

var aryName = document.getElementById('name1').options
[document.getElementById('name1').selectedIndex].text.split(/&nbsp;/);

The select object's name is "name1". I've tried using regular spaces
and mixing the two, but can't figure this out. The goal I'm after is
that when the user clicks on a persons name from the select object,
their name (according to the value of the text) is split and put into
several text boxes that corresponds to the persons first, middle,
last, and suffix. I would greatly appreciate any help on resolving
this problem.

Thanks,
Dave

 

[Thomas 'PointedEars' Lahn]

Gang,

Did you mean "Hello group"?

[...]
The select object's list is created (successfully) with a 'for' loop
in php using the following code:

Posting PHP code in a JS group is rather pointless, for you simply can
_not_ expect people to understand it. Especially, if you have a client-
side problem, post the client-side code, i.e. what is possibly being
generated by server-side code, first. However, as it happens I know my way
around PHP, too.

print "<option value='$val'>".$name[0]."&nbsp;".$name[1]."&nbsp;".$name
[2]."&nbsp;".$name[3]."</option>\n";

<OT>

There are a number of unnecessary concatenations here that make this harder
to read and potentially less efficient. In addition, you should not use
`print' unless you are interested in its constant return value 1 (as in an
expression).

echo "<option value='{$val}'>{$name[0]}&nbsp;{$name[1]}"
. "&nbsp;{$name[2]}&nbsp;{$name[3]}</option>\n";

(There are probably better ways to do this; printf() comes to mind.)

<http://php.net/manual/en/function.print.php>

[...]
var aryName = document.getElementById('name1').options
[document.getElementById('name1').selectedIndex].text.split(/&nbsp;/);

This can be optimized to

var o = document.getElementById('name1');
var aryName = o.options[o.selectedIndex].text.split(/&nbsp;/);

The select object's name is "name1".

No, that is the _element's_ _ID_. However, if `name1' would be the
element's name (i.e., the value of its `name' attribute), you should
use the `elements' collection instead:

formRef.elements["name1"]...

I've tried using regular spaces and mixing the two, but can't figure this
out. The goal I'm after is that when the user clicks on a persons name
from the select object, their name (according to the value of the text)
is split and put into several text boxes that corresponds to the persons
first, middle, last, and suffix. I would greatly appreciate any help on
resolving this problem.

`&nbsp;' is an HTML character entity reference; it is the equivalent of
` ' (or &#xA0). When it is parsed, it ends up as a single Unicode
(UCS-2, really) character in the parse tree, and, as a result, in the
document tree accessible with the DOM API. That is, `&nbsp;' is not
contained as such in the value of the `text' property (which you could have
found out by simply displaying it). Therefore, the split() method cannot
find it, and the return value is _a reference to an Array instance with
only one element_.

<http://www.w3.org/TR/html401/sgml/entities.html>

To display Unicode characters in Unicode-supporting ECMAScript
implementations (of ES2 forward), you can include them verbatim or (better
here) you need to use an escape sequence, here `\u00A0'.

However, using `&nbsp;' does not make sense here in the first place if you
use `&nbsp;' as delimiter everywhere. I have yet to see a renderer that
word-wraps those entries (most notably FF's Gecko does not), so you can use
a space character instead. This would probably also help display as the
non-breaking space character is sometimes displayed narrower or wider than
the space character. And should there be a renderer that word-wraps the
value then in this case it appears to be better to encourage that than to
generate possibly incomplete display. You should use the `white-space:
nowrap' CSS declaration instead; if a renderer or user prefers different
display, they can easily overwrite (or ignore) that value.


PointedEars

 

[Dave]

Gang,

Did you mean "Hello group"?

[...]
The select object's list is created (successfully) with a 'for' loop
in php using the following code:

Posting PHP code in a JS group is rather pointless, for you simply can
_not_ expect people to understand it.  Especially, if you have a client-
side problem, post the client-side code, i.e. what is possibly being
generated by server-side code, first.  However, as it happens I know myway
around PHP, too.

I agree that one can not, obviously, expect the people here to
understand php and as a result I only posted a single line from the
php code to display to everyone what was going to be parsed. This
would provide insight to anyone that offered to help to see what was
_actually_ being sent to the browser in its most "raw" form. It is a
very simple line of code that can be figured out easily. For anyone
that didn't understand it, I would have been more than happy to
explain it. Also using "possibly generated code" is not a good idea
as that can be were the problem lies and not in the code attempting to
be troubleshot, fixed, updated, etc.

print "<option value='$val'>".$name[0]."&nbsp;".$name[1]."&nbsp;".$name
[2]."&nbsp;".$name[3]."</option>\n";

<OT>

There are a number of unnecessary concatenations here that make this harder
to read and potentially less efficient.  In addition, you should not use
`print' unless you are interested in its constant return value 1 (as in an
expression).

I don't see the below code being any more "readable" than the one I
submitted, however, if you prefer to code it that way in an effort to
help find a solution, be my guest. Also, all findings on echo vs
print say that the speed difference is marginal at best. This could
be opened for debate, however, this is the wrong place to do so. I do
appreciate the tidbit of info on the return value though.

  echo "<option value='{$val}'>{$name[0]}&nbsp;{$name[1]}"
    . "&nbsp;{$name[2]}&nbsp;{$name[3]}</option>\n";

(There are probably better ways to do this; printf() comes to mind.)

<http://php.net/manual/en/function.print.php>

[...]
var aryName = document.getElementById('name1').options
[document.getElementById('name1').selectedIndex].text.split(/&nbsp;/);

This can be optimized to

  var o = document.getElementById('name1');
  var aryName = o.options[o.selectedIndex].text.split(/&nbsp;/);

Is this really optimized? Instead of parsing a single line of code, I
have to spend more resources and time assigning an object to a
variable, then processing the request. This might be another echo vs
print situation.

No, that is the _element's_ _ID_.  However, if `name1' would be the
element's name (i.e., the value of its `name' attribute), you should
use the `elements' collection instead:

oops! You're right. I was a victim of saying one thing and thinking
another.

  formRef.elements["name1"]...

I've tried using regular spaces and mixing the two, but can't figure this
out.  The goal I'm after is that when the user clicks on a persons name
from the select object, their name (according to the value of the text)
is split and put into several text boxes that corresponds to the persons
first, middle, last, and suffix.  I would greatly appreciate any helpon
resolving this problem.

`&nbsp;' is an HTML character entity reference; it is the equivalent of
` ' (or &#xA0).  When it is parsed, it ends up as a single Unicode
(UCS-2, really) character in the parse tree, and, as a result, in the
document tree accessible with the DOM API.  That is, `&nbsp;' is not
contained as such in the value of the `text' property (which you could have
found out by simply displaying it).  Therefore, the split() method cannot
find it, and the return value is _a reference to an Array instance with
only one element_.

I did display it and you're right that &nbsp; was not in the output.
However, I did find that when using &nbsp; over a space character, I
was able to preserve the correct amount of spaces between the
different parts of the name so when it was parsed, the parts of the
names could be separated correctly. I also tried to use &nbsp; over a
regular space because what would happen if the person had two middle
names that wasn't hyphenated? Instead of there only being 4 parts to
the name (first, middle, last, suffix), now there would be 5. Now we
have a bug...

<http://www.w3.org/TR/html401/sgml/entities.html>

To display Unicode characters in Unicode-supporting ECMAScript
implementations (of ES2 forward), you can include them verbatim or (better
here) you need to use an escape sequence, here `\u00A0'.

However, using `&nbsp;' does not make sense here in the first place if you
use `&nbsp;' as delimiter everywhere.  I have yet to see a renderer that
word-wraps those entries (most notably FF's Gecko does not), so you can use
a space character instead.  This would probably also help display as the
non-breaking space character is sometimes displayed narrower or wider than
the space character.  And should there be a renderer that word-wraps the
value then in this case it appears to be better to encourage that than to
generate possibly incomplete display.  You should use the `white-space:
nowrap' CSS declaration instead; if a renderer or user prefers different
display, they can easily overwrite (or ignore) that value.

In regards to &nbsp; not making sense as a delimiter, see the above
reply. In this situation, I'm not interested in word wrapping as the
text value is a value to an option in a select form object (which I've
never seen word wrapped options in a select/listbox/combobox). I most
likely will have to keep the &nbsp; or one of your afore mentioned
escape sequences so that the output to the user is normal (ie "first
middle last suffix" instead of something like
"first_middle_last_suffix"). Using &nsbp; (or an escape sequence)
provides the normal appearance while providing a character to split
the string correctly.

PointedEars

Dave

PS.
I did end up getting it to work in FF (haven't tested IE or Opera
yet) by keeping the &nbsp; in the print statement of the php code and
using the \u00A0 as the javascript split "character". Thanks for the
info on the escape codes! Can anyone see any issues with doing it
this way?

 

[Thomas 'PointedEars' Lahn]

[...]
The select object's list is created (successfully) with a 'for' loop
in php using the following code:

Posting PHP code in a JS group is rather pointless, for you simply can
_not_ expect people to understand it. Especially, if you have a client-
side problem, post the client-side code, i.e. what is possibly being
generated by server-side code, first. However, as it happens I know my
way around PHP, too.

[...] It is a very simple line of code

By whose standards?

that can be figured out easily.

Again, by whose standards? Perhaps a person like you knowing (claiming to
know) PHP in the first place? It is like asking in English in a Chinese-
speaking newsgroup and vice-versa (both are natural languages).

For anyone that didn't understand it, I would have been more than happy
to explain it.

Trying to force people to ask questions in order to understand your
question is not a good strategy for asking questions. You will be more
likely (and most likely) ignored. (Did you not wonder why there has been
only one reply by comparison?)

Also using "possibly generated code" is not a good idea

Yes, it is.

as that can be were the problem lies

Yes, therefore you should post that generated code, not the generating one,
in that case.

and not in the code attempting to be troubleshot, fixed, updated, etc.

That is why I said "first"; once it has been ascertained that the generated
code is in error, if necessary a crosspost with Followup-To can facilitate
on-topic discussion about how the generating code (which is most likely not
JS/ES-related) can be modified so that it generates working code.

print "<option value='$val'>".$name[0]."&nbsp;".$name[1]."&nbsp;"
$name[2]."&nbsp;".$name[3]."</option>\n";

[...]
There are a number of unnecessary concatenations here that make this
harder to read and potentially less efficient. In addition, you should
not use `print' unless you are interested in its constant return value 1
(as in an expression).

I don't see the below code being any more "readable" than the one I
submitted,

It is no longer possible to mistake ".$name[0]." for a string literal, for
example. However, had you used some white-space between the operands as
suggested by e.g. PEAR Coding Standards, it could have been equally
readable.

however, if you prefer to code it that way in an effort to
help find a solution, be my guest. Also, all findings on echo vs
print say that the speed difference is marginal at best.

The inefficiency of your PHP code draws from the unnecessary concatenation
(preceded by unnecessary scanning for variable references in double-quoted
strings that do not contain any such reference), not the choice of
function.

[...]
var aryName = document.getElementById('name1').options
[document.getElementById('name1').selectedIndex].text.split(/&nbsp;/);

This can be optimized to

var o = document.getElementById('name1');
var aryName = o.options[o.selectedIndex].text.split(/&nbsp;/);

Is this really optimized?

Most certainly.

Instead of parsing a single line of code,

ECMAScript implementations do not care about code lines with regard to
delimited expressions.

I have to spend more resources and time assigning an object to a
variable,

The object _reference_ is assigned to the variable, following only one-time
scope chain traversal for `document', only one-time prototype chain
traversal for `getElementById', and only one-time [[Call]]ing the reference
in which this lookup results. This gain is compensated afterwards twice by
only short-circuited, comparably easily cacheable, scope chain traversal
for `o' (up to the Variable Object of the current execution context), and
before by only one additional variable instantiation (sic!).

then processing the request.

There is no request involved.

This might be another echo vs print situation.

It isn't. Calling a function twice to return the very same value is
inefficient at best to begin with; I daresay, that holds true for any
programming language. Even more if the function is a DOM method which
needs to traverse the document tree (to find the corresponding element
object), should the reference value not be internally cached.

I did display it and you're right that &nbsp; was not in the output.

That should have indicated to you that it probably fails because you cannot
split on something that simply is not there.

However, I did find that when using &nbsp; over a space character, I
was able to preserve the correct amount of spaces between the
different parts of the name so when it was parsed, the parts of the
names could be separated correctly.

How can that possibly be significant here?

I also tried to use &nbsp; over a regular space because what would happen
if the person had two middle names that wasn't hyphenated? Instead of
there only being 4 parts to the name (first, middle, last, suffix), now
there would be 5. Now we have a bug...
ACK

However, using `&nbsp;' does not make sense here in the first place if
you use `&nbsp;' as delimiter everywhere. I have yet to see a renderer
that word-wraps those entries (most notably FF's Gecko does not), so you
can use a space character instead. This would probably also help
display as the non-breaking space character is sometimes displayed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
narrower or wider than the space character. [...]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[...] Using &nsbp; (or an escape sequence) provides the normal ^^^^^^^^^^
appearance while providing a character to split the string correctly. ^^^^^^^^^^

No, it does not.

[...]

I did end up getting it to work in FF (haven't tested IE or Opera
yet) by keeping the &nbsp; in the print statement of the php code and
using the \u00A0 as the javascript split "character".

There is no "javascript", and there is no reason to put the word in quotes
here.

Thanks for the info on the escape codes!

You are welcome.

Can anyone see any issues with doing it this way?

I have already told you.


Please trim your quotes to the necessary minimum to retain context;
summarize (with `[summary]') where necessary. Do not quote signatures
(unless you refer to them directly).

<http://jibbering.com/faq/#posting>


PointedEars

 

[Dave]

PointedEars
--
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

Oh you're an arguer... Good luck with that...

Dave

 

[Thomas 'PointedEars' Lahn]

That's a signature (considered not part of the posting), which would have
been obvious had you not used buggy Google Groups. Why did you quote it
anyway?

Oh you're an arguer... Good luck with that...

If you are out of good (counter-)arguments, that is *your* problem.


PointedEars

 

[John G Harris]

There is no "javascript", and there is no reason to put the word in quotes
here.

<snip>

Why do you object to the word 'javascript' as the generic name for a lot
of different languages ?

You can't say 'ECMAScript based languages' because some implementations
in use were produced before there was an ECMA standard, and many were
produced before the current ECMA standard settled down. The current ISO
standard, ISO/IEC 16262:2002, is not derived from the current ECMA
standard either.

John

 

[Dave]

That's a signature (considered not part of the posting), which would have
been obvious had you not used buggy Google Groups.  Why did you quote it
anyway?


If you are out of good (counter-)arguments, that is *your* problem.

PointedEars
--

lol and my point is confirm! I have "counter arguments", but thats
just what this would become... an argument, not a debate or anything
healthy. One of us has to be the adult in this situation and not "add
fuel to fire". At this point, you aren't helping any further by your
posts. They're condescending and useless. You did help by providing
information on the use of the escape codes, which I appreciate.
However, the OP has been resolved and now I'm looking for additional
comments/concerns with why using &nbsp; as a delimiter might cause
problems. So far you have failed to help with this. Unless you're
going to add something positive in the form of an answer or resolution
(or even constructive Creticism), please stop posting to the thread.

By the way, it's obvious that your technical knowledge is very good
(give credit where credit is due). If you would work on your
communication skills, you would help more hinder.

http://dictionary.reference.com/browse/etiquette

Dave

 

[Thomas 'PointedEars' Lahn]

Why do you object to the word 'javascript' as the generic name for a lot
of different languages ?

It is promoting the misconception that there is only one programming
language to consider.

You can't say 'ECMAScript based languages' because some implementations
in use were produced before there was an ECMA standard

Those were JavaScript 1.0 (and perhaps 1.1) and JScript 1.0, which are no
longer of any practical concern.

and many were produced before the current ECMA standard settled down.

The current _ECMAScript_ standard (ES5) is not of concern regarding the
terminology.

Only two (or three) implementations were produced before ECMAScript
Edition 1 which was an attempt to standardize features they had in
common. I daresay that makes them implementations of ECMAScript.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
PointedEars
--

That's a signature (considered not part of the posting), which would
have been obvious had you not used buggy Google Groups. Why did you
quote it anyway?

Oh you're an arguer... Good luck with that...

If you are out of good (counter-)arguments, that is *your* problem.
[...]

lol and my point is confirm!

^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No, if anything your lack of knowledge about the English language and
Usenet etiquette has been confirmed.

I have "counter arguments", but thats
just what this would become... an argument, not a debate or anything
healthy.

A (healthy) debate *consists of* arguments and counter-arguments
(cf. Aristotle et al.) "Argument" is a word with different meanings;
check your dictionary.


PointedEars

 

[John G Harris]

It is promoting the misconception that there is only one programming
language to consider.

You'll need to use a long phrase then, such as 'the class of languages
that extend some version of ECMAScript or a close relative'. That's far
too long for general use; you then need a short identifier. Several of
us think that 'javascript' is a suitable short identifier.

I know that a plural word would be more accurate, but the singular is
common practice in class names. Think Number for a type with many
values, Boolean with two values. Null is unusual with only one value.

You think that some people will think that 'javascript' is one language.
Well, that's what the FAQ is for. Also, you ought to be screaming more
loudly about a name that that is too easily confused with Java.

Those were JavaScript 1.0 (and perhaps 1.1) and JScript 1.0, which are no
longer of any practical concern.

So you decree that we aren't allowed to include them in general
statements?

Are you saying that we must say that getFullYear has always been there?

The current _ECMAScript_ standard (ES5) is not of concern regarding the
terminology.

It must be if you want to say ECMAScript-based.

Only two (or three) implementations were produced before ECMAScript
Edition 1 which was an attempt to standardize features they had in
common. I daresay that makes them implementations of ECMAScript.

No it doesn't. You can't have an implementation of something that
doesn't exist yet.

John

 

[Thomas 'PointedEars' Lahn]

You'll need to use a long phrase then, such as 'the class of languages
that extend some version of ECMAScript or a close relative'.

No, you won't.

That's far too long for general use; you then need a short identifier.

Non sequitur. "ECMAScript implementation" suffices.

Several of us think that 'javascript' is a suitable short identifier.

There is no "us". You really are pitiable, calling for big brother.

I know that a plural word would be more accurate,

Good. Why don't you have the courage of your convictions?

but the singular is common practice in class names.

It's not a class name.

Think Number for a type with many values, Boolean with two values. Null
is unusual with only one value.

Neither identifier is a class name. You don't know what you are talking
about.

You think that some people will think that 'javascript' is one language.

Undoubtedly most people will think that as there are, of course, more
people who don't know these languages well than who do.

Well, that's what the FAQ is for.

If "javascript" enters common use, there will be occurences of it where
there is no FAQ reference to explain it. That is the problem with the FAQ
(author) inventing a term out of lazyness and trying to spread it without
thinking that through.

I have already seen the misconceptions to which wrong/invented terminology
has lead, so one does not need to be an augur to say what is likely going
to happen if this misuse continues. See, for example, position #2 in
< where the author of the reviewed
code attributed standards-compliant, implementation-specific behavior to a
bug in the other runtime environment because of an obvious misconception
about a single programming language named "Javascript" that they thought
they used.

also, you ought to be screaming more loudly about a name that that is too
easily confused with Java.
Nonsense.


So you decree that we aren't allowed to include them in general
statements?

(The strong "we" again. You are such a luser.)

No, I am merely saying that your argument is flawed.

Are you saying that we must say that getFullYear has always been there?

(See above.)

Of course not. However, it is not reasonable to assume that there is still
an implementation in use that does not support this method. Providing a
reasonable, traceable basis for such recommendations, in contrast to a mere
gut feeling, is one important reason why I am maintaining the ECMAScript
Support Matrix.

It must be if you want to say ECMAScript-based.

I don't want to say that, you do.

No it doesn't. You can't have an implementation of something that
doesn't exist yet.

Yes, you can; JavaScript versions 1.6 and above have proven that already.

Besides, ECMAScript as the idea of a language standard existed long before
a formal Specification was drafted or published, starting at the latest
with Microsoft officially forking JavaScript 1.0 as JScript 1.0 in 1996-08.


PointedEars