Dynamic selects using optgroups not working in IE

[Pascal Ehlert]

Hi group!

I was trying to build a JS solution for related select lists (child
lists gets populated depending on the value selected in parent list),
which uses no Ajax and is still "usable" in an environment with JS
disabled. 
I have done this with the Low Pro framework which basically
just registers event handlers on certain elements chosen by CSS
selectors.
This is the result: 
http://pastie.caboo.se/136818
The initialize function first sets this.child to the next child element
(css classes "related" and "child") it can find, then parses it's
options (I have used option groups there which are still meaningful
without JS) and saves it to this.grouped_options. 
Now as soon as the
parent value changes it populates the child list from the stored
options.
That not only sounds nice but also works, with one major drawback..

The reason for my post. It works fine in Firefox and Safari but it
doesn't work at all in Internet Explorer 6 or 7.
It just stops, gives some IE typical error messages with non-existing
line numbers etc. and doesn't even remove the old options from the
child list.
Here is a live example: 
http://odatest.hacksrus,net/sandbox.html
I hope someone can help me out and since I'm still a newbie to JS, I'd
also appreciate all other tips concerning the code.
By the way.. I've even heard that it works sometimes, it's really weird..


Regards
Pascal

 

[David Mark]

Hi group!

I was trying to build a JS solution for related select lists (child
lists gets populated depending on the value selected in parent list),
which uses no Ajax and is still "usable" in an environment with JS
disabled. 
I have done this with the Low Pro framework which basically
just registers event handlers on certain elements chosen by CSS
selectors.
This is the result: 
http://pastie.caboo.se/136818
The initialize function first sets this.child to the next child element
(css classes "related" and "child") it can find, then parses it's
options (I have used option groups there which are still meaningful
without JS) and saves it to this.grouped_options. 
Now as soon as the
parent value changes it populates the child list from the stored
options.
That not only sounds nice but also works, with one major drawback..

The reason for my post. It works fine in Firefox and Safari but it
doesn't work at all in Internet Explorer 6 or 7.
It just stops, gives some IE typical error messages with non-existing
http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork

line numbers etc. and doesn't even remove the old options from the
child list.
Here is a live example: 
http://odatest.hacksrus,net/sandbox.html

No, that is a dead link (even with the typo corrected.)

 

[Thomas 'PointedEars' Lahn]

I was trying to build a JS solution for related select lists (child
lists gets populated depending on the value selected in parent list),
which uses no Ajax and is still "usable" in an environment with JS
disabled. 
I have done this with the Low Pro framework which basically
just registers event handlers on certain elements chosen by CSS
selectors.
This is the result: 
http://pastie.caboo.se/136818
The initialize function first sets this.child to the next child element
(css classes "related" and "child") it can find, [...]

I would hope Low Pro would mean "Low Profile", because that is what it
should keep. Once you stopped using the Prototype junk and everything that
is based on it, including Low Pro, someone here might actually be inclined
to analyze your problem. And please get rid of the nonsensical Unobtrusive
JavaScript notion while you are at it.


PointedEars

 

[Pascal Ehlert]

Hi again,

I would hope Low Pro would mean "Low Profile", because that is what it
should keep. Once you stopped using the Prototype junk and everything that
is based on it, including Low Pro, someone here might actually be inclined
to analyze your problem. And please get rid of the nonsensical Unobtrusive
JavaScript notion while you are at it.

What's so bad about JS frameworks? (Or don't you mean frameworks in
general but Prototype in particular?)
Could you please explain? "Get rid of it" isn't much better than
"doesn't work".


Pascal

 

[Thomas 'PointedEars' Lahn]

What's so bad about JS frameworks?

The utter incompetence of most of their authors (especially the most
celebrated ones) that becomes apparent when peer-reviewing their code.

(Or don't you mean frameworks in general but Prototype in particular?)
Both.

Could you please explain?

Certainly not. Search the newgroup's archives, we have already discussed
this here /ad nauseam/.

"Get rid of it" isn't much better than "doesn't work".

In that case, the latter is the justification for the former.


PointedEars

 

[David Mark]

The utter incompetence of most of their authors (especially the most
celebrated ones) that becomes apparent when peer-reviewing their code.

No question about that.

I recently stumbled across a proposed outline for a new book on
JavaScript by the jQuery guy. One of the chapters will apparently
address get/setAttribute. Here's hoping he actually learned how to
handle those since the last time he discussed the subject here. I
think I saw opacity in there too (which he frequently cites as an
example of something that requires user agent string parsing.) I
didn't see a specific chapter on browser sniffing, but I expect it
will be a recurring theme.

 

[Pascal Ehlert]

Hi again!

Once you stopped using the Prototype junk and everything that
is based on it, including Low Pro, someone here might actually be inclined
to analyze your problem. And please get rid of the nonsensical Unobtrusive
JavaScript notion while you are at it.

Thanks so much! That was actually the best advice you could have given to me.
It's so much easier to debug etc. without that crap. Looks nice, smells
shitty

I will ask a more meaningful question next time!


Regards
Pascal