If you are seeing this message, it is possible the page did not load properly. Please hit reload/refresh on your browser.
If you still see this message, you probably do not have a browser that supports
web standards, although its content is accessible to any browser or Internet device.
Posted: 3/22/03 8:49 pm How to Test Scripts and Debug Scripts
There are two main methods to test scripts. One is more time-consuming and the other is more costly.
The first method is to purchase another gold board for testing purposes. Make it identical in as many ways as you can to your "live" board and put some test threads and things in it. This can also prove a very good resource for training new moderators and admins in.
The second method, which can also be used in combination with the first, is to create copies of your board pages on your local hard drive, which you can then change in order to test the effect of a script on your board without affecting your user's experience.
Using the first method is pretty self-explanatory, so let's skip over that for the moment and talk about some tips on using the second method.
Posted: 3/22/03 9:00 pm Re: How to Test Scripts and Debug Scripts
Phase 1: Preparations
A: Custom HTML Section
1. Go into your "My Community" area and into the "Custom HTML" section.
2. Inside of each box except for the BODY one, enter HTML comments that say "begin custom SECTION" at the beginning and "end custom SECTION" at the end.
<!-- begin custom HEAD -->
<!-- end custom HEAD -->
<!-- begin custom HEADER -->
<!-- end custom HEADER -->
<!-- begin custom FOOTER -->
<!-- end custom FOOTER -->
3. If you are not using the box already, check the checkbox that says "use custom SECTION" and put the comments in the empty box anyways.
4. Save your changes.
B: General Settings
1. Go to the "General Settings" section and put in HTML comments in the "Announcement" section.
<!-- begin board announcement -->
<!-- end board announcement -->
2. Save changes.
C: Forum Settings
1. Go to the "General Settings" for at LEAST your first forum.
2. Enter HTML comments in the "Forum Display Name", "Description" and "Introduction" areas. You should know what HTML comments look like by now, so I won't type them out for you again
Posted: 3/22/03 9:10 pm Re: How to Test Scripts and Debug Scripts
Phase 2: Making Your Local "Test Board"
A: Creating Directories
1. Create a directory on your computer to store your "test board" on. If you have some webspace, make this directory a subdirectory of the directory in which you store your other files for your website. I.e. if your local copy of your website is at C:\mysite\www\ then you would put your local test board in a new directory called C:\mysite\www\testboard\
If you don't have webspace... get some! It will be invaluable in getting help with any scripts you are having trouble with.
Got it? Good!
B: Making the "Local Board"
1. Go to the main page of your board ( http://go.ezboard.com/bMYBOARD ).
2. View the source of the page from your browser ( view/source on IE ).
3. Save the source code as an HTML file (usually File/Save As) named "testboard.html" in the directory you created in step 2:A:1.
4. Go to the forum that you added comments to in the preparation phase and view the source.
5. Save the source code as an HTML file named "testforum1.html" in the same directory as your testboard.html file.
6. Repeat steps 4 and 5 for each forum you'd like to have in your local copy of your board. Only one is necessary.
7. Go to a good-sized thread (preferably with signatures and different levels of user who have posted) and view the source.
8. Save the source code as an HTML file called "testtopic.html" in the same directory as your "testboard.html" and "testforum.html" files.
9. Repeat for different topics if desired.
10. If you are working with scripts that affect the add/reply screens, save a copy of a new topic page and an add reply page (and add poll if you like), too. Call them "testnewtopic.html" and "testaddreply.html" or something similar. The important part is that you know what each test page is simply by looking at it.
11. At this time it might be a good idea to save a backup copy of all of the files you created, just in case.
Posted: 3/22/03 9:14 pm Re: How to Test Scripts and Debug Scripts
Phase 3: Software
1. You will want to have a good text editor to use when you are modifying your test board. There are a lot of good ones out there and even the ones that come with your OS (notepad on windows) are OK. Personally, I use a program called "Edit Pad Pro". It costs about $30 bucks to register but it's very good.
The key feature you want to look for is the ability to know what line number you are on in your HTML file. This will help you TREMENDOUSLY when you are debugging a script.
Posted: 3/22/03 9:20 pm Re: How to Test Scripts and Debug Scripts
Phase 4: Installing Scripts on Your "Local Board"
A: Where does it go? What do I need to change to test it?
1. Once you've found a script you want to try out, you'll need to figure out which pages on your board it would effect. If it would only effect the main page, you'll only need to install it on your "testboard.html" file. If it might affect forums and topics, too, install it there.
IMPORTANT NOTE: Many scripts use a technique of looking at the page's location to see if the page is the main board, a forum, a topic or some other screen. That usually looks like this:
if ( document.location.href.indexOf("SOMETHING") != -1 ) { ...
You will need to understand where these are used and why in order to use the "Local Board" testing method with these scripts.
For instance, if the code is supposed to change links but only on the main board, it might have this code:
When you install that script on your test board, you will need to comment out the if statement and the closing bracket in order to test it on the correct pages. On the pages that don't match, you don't need to comment out anything.
If you are having trouble with this, ask on the JavaScript and Java help board and hopefully someone will be able to give you a copy of the code with those location tests commented out.
Posted: 3/22/03 9:29 pm Re: How to Test Scripts and Debug Scripts
B: Installing the Script
1. If the script is supposed to go in the custom HEAD section of your board, go into the local board page (for example, "testboard.html") and find where you see the HTML comment: <!-- begin custom HEAD -->
Add your script somewhere after that but before the end custom HEAD comment.
Whichever section it is supposed to be in, put it between the start and end comments for that section.
2. Repeat step 1 for each part of the script, as necessary and for each page which would be affected by the script, as necessary.
This may vary widely from script to script.
NOTE: Some scripts don't tell you where to put them. I personally recommend that you try the custom FOOTER section if none was specified.
ANOTHER NOTE: Some scripts don't start with the <script type="text/javascript"> tag or end with the </script> tag. If this is the case, you'll want to put those tags in yourself, or put it at the end of an existing script.
YET ANOTHER NOTE: If the script doesn't have comments in it already to say what it does, go ahead and add one. At the very top of the script, add a line that says:
// SCRIPT NAME: This script is designed to .....
This way you can separate the different scripts you have installed and be able to recognize what code goes with what script more easily.
Posted: 3/22/03 9:34 pm Re: How to Test Scripts and Debug Scripts
C: Testing the Script
1. Once you have the script installed on your local board, open the browser you need to test the script in, and load the files you changed.
2. In Internet Explorer, you do this by using the File/Open menu command and then browsing to where the file is. On Netscape / Mozilla, you do this by using the File/Open File menu command.
3. Repeat steps 1 and 2 for each browser and page you need to test.
4. If the script works how you want it to, GREAT! If not, continue on to Phase 5: Debugging before coming back here to Phase 4: Section D: Installing on Your Live Board.
Posted: 3/22/03 9:42 pm Re: How to Test Scripts and Debug Scripts
D: Installing on Your Live Board
Once you've got a script that is working how you want it... you're all set to move it over to the live board.
1. Open up the first file that you changed when you installed the test copy of the script.
2. For each section that you changed:
a. Take out any javascript comments you put in, the ones that you may have added in Phase 4: Section A, Step 1 (the IMPORTANT NOTES)
b. Copy the ENTIRE section out of the test board code, including the begin and end HTML comments.
c. Go to that section on your live board and delete the existing code.
d. Paste the code from step b into the box on your live board.
3. Repeat step 2 for all the sections that you changed.
4. Go through the board, looking for problems and errors to come up on the board screen, forum screen, topic screens and reply screens.
If you get errors on your live board, replace the code with the code from your backups from Phase 1: Section B, Step 11. I told you it was a good idea to make backups!
Try to figure out what might be different between the live board and the test pages you made... ask questions on the Javascript Help Forum if you need help... but give specific errors and be as descriptive as possible.
Now is also a good time to get a test board if you don't already have one.
5. If your script works fine, you're all set! If not, continue on to Phase 5: Debugging Scripts
Posted: 3/22/03 9:53 pm Re: How to Test Scripts and Debug Scripts
Phase 5: Debugging Scripts
Internet Explorer and Netscape / Mozilla both have integrated script error reporting which can be very useful to us. Each one is a little different so we'll talk a little about the way each browser displays JavaScript errors.
Our first line of defense in debugging is to make sure that the syntax (all those brackets and colons and things) of the script is correct.
A: JavaScript Errors In Internet Explorer
In the default configuration, Internet Explorer reports errors by putting a little yellow triangle in the lower right-hand corner of the status bar. Typically it says "Done, but with errors." next to the icon.
To view errors, double-click on the yellow icon. It will give you some text that tells you what the error is (usually pretty technical and sometimes hard to understand) and the line number where the error was generated.
The line number is perhaps the most important piece of information that it tells us!
If you get a JavaScript error that tells you:
Line: 15
Char: 6
Error: Object doesn't support this property or method
It probably means that you have a typo on line 15. Go into your text editor and go over line 15 very carefully. Post the script and the error message on the help forum if you can't find anything wrong (don't just post line 15 but tell us which line is line 15!)
Posted: 3/22/03 9:59 pm Re: How to Test Scripts and Debug Scripts
B: JavaScript Errors in Netscape Navigator / Mozilla
JavaScript error reporting in Netscape Navigator is usually much better than JavaScript error reporting in IE. To look at JavaScript errors, warnings, etc, you will need to first open up the JavaScript console by entering:
javascript:
into the location box and hitting enter. The javascript console will open up.
To clear the console, use the "clear" button. This will help you to focus on just the errors you are getting from the current incarnation of the script.
After you have the console open, navigate to the page you are debugging.
When errors occur in the script, they are logged in the console for you to look at.
Here is an example of the same error from the internet explorer section as reported by Netscape:
Error: document.writ is not a function
Source File: file:///C:/Documents%20and%20Settings/void/Desktop/scrollbox.html
Line: 15
Do you see how much better that is? It is actually showing us what part of the script I typoed! I forgot to put an e when I typed "document.write"!
Now we go back to our script and fix the typo. Next we clear the javascript console with the "clear" button and then we refresh the page.
No more errors!
I highly recommend doing any "hardcore" debugging you need to do in Netscape. You can also use the Microsoft Script Debugger application, but that is not necessarily very reliable and I am not going to give any tips on it's use here.
Posted: 3/22/03 10:09 pm Re: How to Test Scripts and Debug Scripts
C: Logical Versus Syntax Errors
When you just plain typed the wrong thing, it usually results in a syntax error that you can see in the browser.
When the browser reports no errors but your script doesn't do what it is supposed to do (or worse yet, it does something ISN'T SUPPOSED TO DO!), then you are probably trying to find a logical error as opposed to a syntax error.
Logical errors are errors in the code, either in the logic of how the code flows from one statement to the next (ifs and elses and fors and whiles and the like) or errors in the logic of which objects / variables you are manipulating and/or how you got your data.
Logical errors and their counterpart -- valid logical constructs are what programming is all about. How to construct valid logical code is more than I can cover here... so you're on your own there.
However, I can give you a couple of tips on how to try and figure out WHERE your logical errors are coming in.
Posted: 3/22/03 11:00 pm Re: How to Test Scripts and Debug Scripts
When debugging logical errors, the alert() function is your best friend.
The first use of an alert in debugging is to place the alert inside of a "block if" to see if the statements are being executed (i.e. the conditional expression for the if evaluated to true).
Example:
if ( x == 1 ) {
alert( "x == 1 is true");
document.write("x is 1");
}
When your conditional expression ( x == 1 ) is evaluated to be true, then the alert occurs, as well as the following statements.
The second use of an alert is to show you the value of data which you are changing or checking with conditional expressions. It will help you to determine whether the data you are getting is the data that you were expecting to get when you wrote the code.
Example:
if ( x == 1 ) {
alert( "x == 1 is true");
document.write("x is 1");
} else {
alert("x is not 1, x is " + x);
}
OR
alert(x);
if ( x == 1 ) {
alert( "x == 1 is true");
document.write("x is 1");
}
Now we know for sure what the value of X is and can adjust our code accordingly.
Posted: 3/22/03 11:52 pm Re: How to Test Scripts and Debug Scripts
D: Objects and Collections
When using JavaScript to achieve DHTML (dynamic HTML) effects or to manipulate the contents of a webpage (which is usually what we use it for on EZBoard), we are always working with objects and collections that represent the webpage our script is executed from or the browser that the user is visiting our page from.
According to the DOM (document object model), each HTML tag on a page is an object in the document heirarchy. These objects are called nodes or elementNodes.
Each separate piece of text on the page is also an object in the heirarchy which is called a textnode.
The DOM model describes the way in which nested HTML tags operate, creating a parent-child relationship between the HTML tags (childNodes) inside of another pair of HTML tags (parentNode).
For example, take the following HTML:
<p><span class="important">something important</span> is going on here soon.</p>
This HTML describes a paragraph with a span inside of it and some text inside of it. The DOM for this HTML includes a paragraph elementNode (p), a span elementNode which is a child of the paragraph node (span), a textNode which is a child of the span node (something important), and a textnode which is a child of the paragraph node (is going on here soon).
When coding and debugging JavaScript, a firm grasp of the organization of the DOM is crucial to the ability to manipulate elements of a webpage. You should learn to look at HTML and be able to figure out how the relationship between HTML tags will translate into parent-child relationships in the DOM.
With this knowledge you will be able to take advantage of the DOM properties and object collections which are exposed by today's modern browsers.
Rather than a complete DOM primer (which is again beyond the scope of what I am trying to show here), I would just like to show you some objects, collections and properties that I have found useful in manipulating EZBoard pages and most specifically, some properties and methods of those objects and collections that you can use when debugging DOM scripts.
The information here is basically culled from the Microsoft DHTML references available at:
The document object is the granddaddy of them all. Since it sits at the top of the DOM heirarchy, we will use the document object to find "object references" to every other object and collection that we manipulate with JavaScript.
We will obtain these references through properties, collections and methods of the document object.
METHODS:
Methods of the document object can be used to create new nodes and to retrieve references to existing nodes inside the document.
document.getElementById(elementid) --
This method will return a reference to an object with the specified ID. IDs are a unique identifier so the document.getElementByID method will only return one object reference. elementid can either be a variable which contains a string corresponding to the ID you want to retrieve the object of or a hardcoded string.
Example:
var navBar = document.getElementById("navbar");
This will make the variable navBar a reference to the HTML object with the ID of "navbar". (for instance, a div: <div ID="navbar">.... </div> )
document.getElementsByName(elementname) --
This method returns a collection of objects with the specified name. If there are no objects with that name in the document, the length property of the collection will be 0. Individual objects are referenced using the item property of the collection.
Example, HTML contains:
<span name="go">go!</span>
.....
<span name="go">really, I mean it! Go!</span>
.....
<span name="go">don't stop!</span>
JavaScript:
var allGos = document.getElementsByName("go");
alert(allGos.length);
alert(allGos.item(0).innerHTML);
alert(allGos.item(1).innerHTML);
alert(allGos.item(2).innerHTML);
Running this code would result in popups that say "3", "go!", "really, I mean it! Go!" and "don't stop!".
A quick way to get the first object with a particular name (when you are SURE it will be there) is to set the object reference directly to the first item in the collection:
var oGo = document.getElementsByName("go").item(0);
alert(oGo.innerHTML);
This will result in a popup that says "go!".
METHODS THAT APPLY TO ALL OBJECTS:
You can use these methods with the document object, or with other objects such as ones you get with the document methods.
object.getElementsByTagName(tagname) --
This returns a collection of objects with the specified tagname. If tagname is "p", then it will return each paragraph object which is a child, grandchild, etc. of the supplied object.
Example, HTML:
<body>
<p>nothing particular.</p>
<p><span>something</span> else</p>
<p><span>well,</span> still nothing.</p>
</body>
This code will output "3" (number of paragraphs), "2" (number of span tags), make an object reference to the first paragraph and then output "0" (the number of span tags in the first paragraph).
PROPERTIES OF OTHER OBJECTS:
Here are some useful properties you might want to use in conditional expressions, that you might want to change or that you might want to use in alerts as you write and debug scripts:
object.className -- the CSS class assigned to the object with the "class" attribute in HTML or with script. Can be changed.
object.innerHTML -- a reference to the HTML contained within the object, the raw HTML which contains/creates the childnodes of the object. THIS IS A NON-STANDARD PROPERTY. While this property is supported by IE and Netscape, it is not part of the DOM standard.
object.name -- the name supplied to this node in an HTML attribute or through script. SEE document.getElementsByName
object.nodeName -- the name of the ELEMENT for this node, not this' node's name. For example, a div HTML element would be return "DIV" for this property.
object.nodeType -- the nodetype of this node. 1 is an elementNode, 3 is a textNode, etc.
object.firstChild -- a reference to the first child object -- the next nested tag or piece of text. BE CAREFUL! Sometimes this is a textnode with just a linebreak in it!
object.lastChild -- the last child node that is nested inside of this object. Could be a piece of text, be careful!
object.previousSibling -- the node immediately preceding the current node. May be a textnode -- be careful!
object.nextSibling -- the node immediately following the current node. May be a textnode -- be careful!
object.parentNode -- an object reference to the node which is above this node in the DOM heirarchy (this node is a childNode of some other node. The body element for example is a childNode of the document node)
Posted: 3/23/03 12:09 am Re: How to Test Scripts and Debug Scripts
object.hasChildNodes -- this property tells us whether a particular object has any children.
COLLECTIONS:
Collections are sort of a special type of object that contain other objects. They have their own properties and their own methods and can be extremely useful to us, so we want to learn them.
object.childNodes --
This collection returns a collection of the direct children of an object.
METHODS:
item(index) --
Returns an object reference to a member of the collection. The member is specified using a 0-based index value.
PROPERTIES:
length --
Returns an integer value representing the count of items in the collection (i.e. if there are 3 items in the collection, it will return 3 items which are then referenced as item(0), item(1) and item(2) )
Example HTML:
<div ID="namelist"><p><a href="/bob.html">Bob</a></p>
<p><a href="/fred.html">Fred</a></p>
<span>These are some names!</span></div>
"P: <a href="/bob.html">Bob</a>"
"P: <a href="/fred.html">Fred</a>"
"SPAN: These are some names!"
You will notice that the A tags inside of the paragraph tags are NOT direct children of the DIV tag and so are not members of the childNodes collection of the DIV tag. They are members of the childNodes collection of their respective enclosing paragraph tags.
Be careful which you use, though -- make sure that the info for the collection says that it is part of the W3C Document Object Model Level 1 before you expect it to work in Netscape and Opera, etc.
Posted: 3/23/03 12:13 am Re: How to Test Scripts and Debug Scripts
E: Using Objects and Collections in Debugging
As you are fine-tuning scripts which are not performing well, it can be very useful to sprinkle your code heavily with alerts that tell you the current value of things like the nodeType, nodeName, className, href, etc. of the objects you are testing or changing.
Part of the big "struggle" with programming for EZBoard scripts is that there are not many IDs to use and so you need to do things like looping through collections of tables, links, tds, or spans.
Using judicious alerts along with careful study of the HTML structure of the page you are working with, you should be able to create a reference to any object which appears on an EZboard page. After you've got the object reference, you can rewrite the HTML inside, move the object to a different place on the page, give it an ID for later use, change it's CSS class -- the possibilities are endless.
Posted: 3/23/03 12:20 am Re: How to Test Scripts and Debug Scripts
Phase 6: Wrapping Up My Tips
When you come to a problem that you just can't solve with any of these tips and study of your code ... upload your test board to a webserver and give us the URL of the page. It will let us have a look at what you are actually working with without necessitating a test board or crippling your live board while you obtain help with the scripts you are having trouble with.
With these suggestions and notes, it should be easier for any EZBoard admin to install pre-written scripts. It should also be easier (hopefully) for people just becoming familiar with JavaScript to experiment with altering and customizing the scripts that are already out there to better fit their needs.
And for programmers who are just getting started with scripting EZboard, I hope that it can help serve as a roadmap for how to begin.
The bottom line -- deploying and developing scripts is a complex process. Attention to detail and thorough testing are a must if we want to make sure that our users get the best experience possible.
Testing and debugging "offline" makes this much easier (if only for the lack of pressure of having a broken board!) and more efficient.
Cool Tips & Tricks
:::Edit Post Button
:::Delete Post Button (Moderator Only)
ezboard Help Communities: