21 Nov, 2008, Kayle wrote in the 1st comment:
Votes: 0
Alright. So I got my fonts working, and I got my menus working. But now I have a bigger problem. The javascript that controls the menus, and the javascript that controls the buttons for the post box (the thing you post in when creating a new post for any who don't know) are interacting in a funky way… the easiest way to describe it is to just show you.

This screenshot shows pretty clearly what's going on. Now, The javascript in question is in 3 files: postboxplain.js, library.js, and menus.js. Library.js is the mootools javascript library and if I disable that script (by commenting it out of the html) the undefined buttons aren't there anymore. So I know the problem is somewhere in there. But I don't know enough about javascript to be able to pinpoint it, so I'm hoping someone here can help me figure this out.

[Edit:] On an unrelated note, I can't win with IE. If I get the menus to work, it can't seem to understand <span> tags, but if it doesn't have the menus then.. well. It understands <span> tags. :mutter:
21 Nov, 2008, Igabod wrote in the 2nd comment:
Votes: 0
so switch to firefox? sorry i can't help answer your main question, i'm a java idiot.
21 Nov, 2008, David Haley wrote in the 3rd comment:
Votes: 0
Are the buttons auto-generated, i.e., being generated by QSFP code? It's possible that they're being placed inside a div that is normally hidden, but that the javascript code is enabling. That would explain why disabling library.js makes the div stay hidden. (Or it could be something completely different, of course…)

(BTW Igabod, Java != Javascript, the two are actually very different languages, the name similarity is just a marketing gimmick)
21 Nov, 2008, Kayle wrote in the 4th comment:
Votes: 0
Igabod: I do use Firefox, but when doing web development, since a vast majority of the market share is still help by IE, it's better to make sure your site renders properly on there, just as it does in every other browser. God I hate IE and their inability to conform to the standards they helped create…

David: Yeah they're automatically generated. postboxplain.js is actually fed the text area and then it makes the buttons inserts them into the DOM, and then does the clickable smilies and inserts them as well. I dunno about the hidden <div> or something I dunno, I'll do a little digging, see what I can find.
21 Nov, 2008, David Haley wrote in the 5th comment:
Votes: 0
I'll take a look at it when I get off work if you don't figure it out by then. Can't help with QSFP stuff but I can look at the generated html at least…
21 Nov, 2008, Guest wrote in the 6th comment:
Votes: 0
I was helping Kayle look into this as well but since it involves javascript I don't really have any idea what's going on here. The area of code is something Geoff wrote and he's been out of contact now for quite awhile so I can't go to him for help understanding the problem. Best I can figure is somehow the library code is causing the bbcode control buttons to throw a bunch of extra stuff out. Looking through the generated HTML isn't helping either, view source doesn't even show those buttons as being in the page.
21 Nov, 2008, Kayle wrote in the 7th comment:
Votes: 0
Yeah, It's got me completely puzzled as well, and I've been working on it off and on all day. =/
22 Nov, 2008, Kayle wrote in the 8th comment:
Votes: 0
I"m officially to the point where I'm wringing my hands and ripping my hair out over this. =/
22 Nov, 2008, Guest wrote in the 9th comment:
Votes: 0
I dunno either. Maybe Kiasyn knows? I get the reason for why automatically generating the buttons was done, but maintenance is impossible if nobody is left who understands the code. This is a classic case.
22 Nov, 2008, elanthis wrote in the 10th comment:
Votes: 0
This kind of stuff is impossible to really debug without using a tool like Firebug, just like trying to debug a C application is near impossible without a proper debugger.

It sounds a lot like the menu code is executing something that is altering the page content in an unsafe way, or Mootools is changing the way some part of the DOM behaves in an unsafe way. That is one of the reasons I avoid any toolkit besides jQuery – it's a bit less convenient as it doesn't extend the DOM with a ton of useful methods, but it's way safer because it doesn't extend the DOM with a ton of useful methods.

I might be willing to take a quick peak at it if you give the URL to the page having problems.
22 Nov, 2008, Kayle wrote in the 11th comment:
Votes: 0
I totally forgot about Firebug. I have it installed but I always forget to use it. I'll turn on posting for Guests and you can use this link to see the new post page.
22 Nov, 2008, Igabod wrote in the 12th comment:
Votes: 0
DavidHaley said:
Are the buttons auto-generated, i.e., being generated by QSFP code? It's possible that they're being placed inside a div that is normally hidden, but that the javascript code is enabling. That would explain why disabling library.js makes the div stay hidden. (Or it could be something completely different, of course…)

(BTW Igabod, Java != Javascript, the two are actually very different languages, the name similarity is just a marketing gimmick)


seriously? damn, that might explain part of the reason i was having so much trouble with it when i tried to learn one or the other, i was probably getting info from 2 different things and trying to combine them. either way i'm not too interested in trying to learn either one of them now. thats one of those things that i was interested in years ago.
22 Nov, 2008, Kayle wrote in the 13th comment:
Votes: 0
Igabod said:
either way i'm not too interested in trying to learn either one of them now. thats one of those things that i was interested in years ago.


Javascript is indispensable in the web design world. There is so much you can do with javascript that you can't do with other web design languages, but at the same time, there's a lot of things you can't do with Javascript that you can do with others. Web design is a tricky business and while, yes, you can get by just knowing one, to really go places you really need to have an understanding of all the pieces, and that's something I've come to realize working on this site, not having a truly solid understanding of php, or javascript is really slowing down the progress I'm making on this site. Well, that and these mysterious 19 buttons I can't seem to get rid of…
22 Nov, 2008, Igabod wrote in the 14th comment:
Votes: 0
Kayle said:
Igabod said:
either way i'm not too interested in trying to learn either one of them now. thats one of those things that i was interested in years ago.


Javascript is indispensable in the web design world. There is so much you can do with javascript that you can't do with other web design languages, but at the same time, there's a lot of things you can't do with Javascript that you can do with others. Web design is a tricky business and while, yes, you can get by just knowing one, to really go places you really need to have an understanding of all the pieces, and that's something I've come to realize working on this site, not having a truly solid understanding of php, or javascript is really slowing down the progress I'm making on this site. Well, that and these mysterious 19 buttons I can't seem to get rid of…

lucky for me that i'm not at all interested in web design anymore then huh? i used to enjoy making webpages all the time, course this is back when html was pretty much the only language for web development that i know of. i had to have been about 14 or so at the time.
22 Nov, 2008, elanthis wrote in the 15th comment:
Votes: 0
Firebug proved my point about Mootools and how it extends the DOM and breaks shit. Let's go over what's happening.

1) MooTools adds new methods to the Array global object. These are, generally, quite useful methods. Good things to have. Things we wish JavaScript had by default, but doesn't. Or, at least, doesn't on all browsers, like the almost ten years old IE6.

2) The for and for each expressions in JavaScript iterate over all properties on an object. This includes the properties of the object's prototype. Properties include the things you set on the object as well as the object's methods. In the case of an Array object, this also means all the array indexes.

3) A rather goofy design flaw in JavaScript deals with the iteration issue in #2 for default methods. When you do a for loop over the properties of an Array object, you generally don't want to get results for the Array methods, or the length property, or so on. You just want the indexes. The solution the JavaScript developers had was to allow the runtime to mark a property as non-enumerable; e.g., it is hidden from a for loop. Unfortunately, they did not decide to give user code any way to set the non-enumerable flag; only the core runtime engine can do this.

4) Since MooTools extends the Array object with custom methods, and since those cannot be hidden from a for loop, a for loop over an Array object will thus enumerate both the Array indexes and all those lovely MooTools extension methods.

5) The script that creates the buttons gets an Array full of Objects that have details like title and tag and so on. It uses a for loop to iterate over the Array and create the proper buttons or select boxes.

6) The script, which was expecting just Objects out of the for loop, is now also getting a bunch of Function objects from the MooTools extensions. So it's trying to create a button using these Function objects. It just takes the Function object, copies the title/tag/keynum attributes (which are undefined), and creates the button using those. Henc ewhy the buttons all say "undefined" – the undefined type is converted to the string "undefined" whenever a string conversion is forced.

7) Tada, your page breaks with MooTools.

So, solution: find a different menu code that uses a less harmful JavaScript toolkit. I cannot recommend jQuery highly enough.

Alternatively, in postboxplain.js, on line 154, replace the for loop with the MooTools each() extension. e.g., buttonArray.each(function(button, buttonIndex){ … });

Also alternatively, in postboxplain.js, on line 154, just add: if (buttonArray[buttonIndex].title == "undefined") continue;

The bill's in the mail. ;)
22 Nov, 2008, David Haley wrote in the 16th comment:
Votes: 0
Surely, other people have run into this problem, and there is a workaround with MooTools – lots of people use it, after all, and I'd be fairly surprised if Kayle were the first to hit this problem.

And it looks like he isn't, because MooTools provides its own "each()" extension. :smile:

This is one of the things I somewhat dislike with JavaScript's semantics, incidentally.
22 Nov, 2008, Kayle wrote in the 17th comment:
Votes: 0
I don't care if I'm the first or the last. elanthis showed me how to fix it, and now it's fixed. My mysterious 19 extra buttons are gone. :D Thanks you elanthis for the solution, and thansk everyone for the ideas.
22 Nov, 2008, elanthis wrote in the 18th comment:
Votes: 0
DavidHaley said:
And it looks like he isn't, because MooTools provides its own "each()" extension. :smile:


Which is one of the fixes, yes. It's just dumb that it's necessary. If dropping in a toolkit breaks other, existing code, then the toolkit is broken by design, IMO.
22 Nov, 2008, David Haley wrote in the 19th comment:
Votes: 0
I'd kind of like to argue that a language that allows things to be broken like this is the thing broken in the first place, but, eh. :smile:

How does JQuery achieve the same purpose without introducing this behavior?
23 Nov, 2008, elanthis wrote in the 20th comment:
Votes: 0
I feel compelled to note that I should also have just recommended using a proper for loop for iterating over arrays rather than the for…in syntax, which really wasn't intended for element enumeration in Array objects in the first place. That is, the problem code that started this whole thread could easily be turned into the more correct:

for (buttonIndex = 0; buttonIndex != buttonArray.length; ++buttonIndex) {


DavidHaley said:
I'd kind of like to argue that a language that allows things to be broken like this is the thing broken in the first place, but, eh. :smile:


Heh. I guess C is totally broken, then, given what you can do with macros or even symbol overloading. ;) Same goes for just about any dynamic language. I think Java's the only one that's safe. :p

I actually have had it happen where including the header from a third party library to support a new feature in some function magically broke other existing code in the file, due to poorly chosen macro identifiers.

Technically, by design, JavaScript is not really broken in this regard. The for…in syntax is _supposed_ to iterate over every single property of an object and its prototype chain. What's technically broken is all the code written by people who started using that syntax in places it wasn't actually intended for. The non-enumerable flags set on default properties (which actually was only meant to be set on a small handful of magic properties, e.g. prototype and length, but vendor implementations and later standards mucked that up) let people think it was safe to use for something it's not. Arrays were always meant to be iterated over using the classic for loop approach above.

I'd really prefer that the for…in syntax would just iterate over the expected values, e.g. by ignoring all methods and properties on the prototype, or by calling a specific method to get an Enumerable-like object or something, but that just wasn't how it was designed. The JavaScript design is intentionally very light on syntactic sugar. The only reason the for…in syntax exists at all is because it is the only way to get a list of properties from an object; perhaps it was decided that a special method that returned an Array of property identifiers would be too inefficient for large objects.

It's really a minor annoyance. It's something that catches up a lot of beginners (and thus leaks into a lot of code in the wild, like the broken forum button code), but it really isn't an issue at all for anyone versed in JavaScript. The same goes for the default variable scope being global for newly defined variables. I've always hated it when a language forces me to declare a variable as local or else makes it global; if I have to declare the scope at all, I much prefer PHP's approach of making all variables local unless you explicitly declare it global. (Being a C/C++ junkie, I also quite like it when the language just figures it out on its own based on where the variable is first declared.) A lot of novice code has subtle bugs due to declaring JavaScript variables without using the 'var' keyword, but it's just not something that ever bothers a JavaScript developer with any real experience.

Quote
How does JQuery achieve the same purpose without introducing this behavior?


By being slightly less convenient. You have to wrap an object in a jQuery object in order to use any of jQuery's methods, or you have to use a more procedural approach rather than an object oriented one. e.g.,

jQuery(my_array).each(function(element){ … });
// or
jQuery.each(my_array, function(element){ … });


jQuery has an (optional, on by default) shortcut that lets you use $ in place of jQuery, which can make the above examples a bit shorter and easier. I make it a habit to use jQuery rather than $, however, because almost every JavaScript toolkit uses $() for something, and some of them do not make it optional. By using the jQuery identifier, I guarantee that if my code is ever mixed with code requiring a different toolkit, it'll work without conflicts.

It's worth noting that jQuery does not attempt to be a general purpose JavaScript toolkit, either. It focuses purely on the needs of web developers, and so the vast majority of its convenience and power comes from manipulating the DOM and working with events rather than proving generic utility routines. In turn, it's often a lot easier to write really great web interfaces in jQuery than with any other toolkit, even though certain operations require a little more typing to accomplish in jQuery.

I don't find myself wrapping objects very often in jQuery. The real power of jQuery comes in when you start giving it CSS or XPath selectors and applying jQuery methods to whole groups of matched elements. For example, something like:

// whenever a button with the callback class is clicked, make a JSON
// request to the server, passing in the button's id as input, and taking the
// HTML response and replace it into a content div. update the div's style
// as dictated by the response, and then display a message to the user
// inside a different div.
jQuery('input[type="button"].callback').click(function(button){
jQuery.getJSON('/api', {action:this.id}, function(data){
jQuery('div.content')
.html(data.response.html)
.css('border', data.response.border)
.css('color', data.response.color);
jQuery('#messages').append(jQuery('<span class="message">'+data.response.message+'</span>'));
});
});


That's a rather silly example, but it shows off a few of the primary features. Being able to use CSS selectors – including CSS operators that the browser itself doesn't support – to grab whole groups of elements and apply an event callback to all of them with a single line of code is fantastically powerful. The modifier chaining (and also filter chaining, which I didn't show an example of) makes doing very complex updates very easy. The easy DOM node creation is also quite handy. I think the only thing I see that people often want that jQuery lacks is a method for HTML-escaping a string; however, if you find yourself wanting such a method, I guarantee that you're trying to do something the wrong way.

Quote
// if I wanted to make the message output in the above example HTML-safe…
jQuery('div#messages').append(jQuery('<span class="message"></span>').text(data.response.message));
// or even
jQuery('div#messages').append(jQuery('<span/>').addClass('message').text(data.response.message));


The only toolkit I can even come close to recommending as highly as jQuery is Prototype, and that's only because Prototype has been copying a lot of jQuery's functionality. ;) Prototype still pollutes the type system, though.

… why do I always feel the need to type so much in forum posts? I waste way too many hours of my day doing things like this. :/
0.0/33