Good grief, I need to attach this EVENTHANDLER to something so that I can call the FUNCTION. Not only do I need the stupid EVENTHANDLER to do that, but I also need it to pass a VARIABLE to the ARGUMENT so that it can be used in the STATEMENT. Oh man! I almost forgot that it needs to include a METHOD! How am I ever going to learn all of this stuff? Arrrrgh!
Sound familiar? Probably not. More than likely, at this stage you might say something closer to; I need one of those THINGIES so that the WATCHAMACALLIT can do all that STUFF.
Don't be too dismayed about the jargon at this point. As you need it you will pick it up. (Think of it this way; Can you carry on a conversation without knowing what a parenthetical statement is? See what I mean? By the way... you are reading a parenthetical statement right now.)
A good way to think of scripting is as a language. (duh! it is a language.) You do not have to know what the official term is for some part of grammar to use it, you just have to understand how it works in a sentence or use it correctly by habit. (I am almost certain that last statement would have earned me yet another detention from Mrs. Finnwyck, my eight grade English teacher, had I openly declared it while I was her student. But hey, I'm the teacher now!)
Okay, now you are through the first bit of pain and suffering. You understand that you do not have to know the difference between a "user defined function" and a "method" in official terminology ( a better term would be "Geek Speak") as long as you know how to use them. But now the second big wave of anxiety hits as you realize that you don't really understand how to use this stuff.
Before you decide to change your major to something easier, like medicine, hear me out. You don't really have to have memorized every bit of a scripting language to understand enough to use it. All that you really need are a few of the fundamentals and to know how to find the additional information that you need. (You can read a book, can't you?)
I have been writing JavaScript for years. I can sit down at a computer, open Notepad, and type out a script from scratch. But I don't. Usually the first thing that I do when writing a new script is grab a book (Well, sometimes about 5 books). I scan the pages for a script that does something similar to the one that I am trying write and I copy it. I then alter it to do the specific things that I want my script to do. If I don't find what I am looking for in a book, I begin searching the web. Actually it is easier when I find it on the web because then I can just copy the script and paste it in my own document. If there is some part of the copied script that I don't understand, I hit the books again and study the mysterious part. By doing it this way I save a lot of time and I have a lot less errors to debug. "But that is cheating!", you might say. Well, would you set out to build a rocket without looking at what other engineers have designed before you? And I bet that you would spend a lot more time looking at other rockets that have worked, than you would those that blew up on the launch pad.
Before we go on, let's recap:
You don't have to know all of the Geek Speak to write a script that works.
You don't even have to know how to write a certain kind of script because you can always find a working example and alter it to fit your needs.
And last, if there is some part that you can't figure out you can always look it up.
So far, so good. Feeling better? You will until someone asks you to write code in something other than JavaScript. Then you'll freak... even if you shouldn't.
But I only know how to use JavaScript! I don't know any of the other languages!
Actually you know nearly everything that you need to know to write in most of the languages that you might use for coding because they are all based on the same system. You can easily apply the same philosophy that I have suggested for JavaScript to anything else. It is only a matter of looking up the differences. Let me show you.
If you were going to write a script using JavaScript that printed out "Hello!" on a web page you would write something like this:
<script language="JavaScript">
document.write("Hello!");
</script>
Simple enough, but now let's throw in the specter of another scripting language. This next section will be in a language called VBScript.
<script language="VBScript">
document.write("Hello!");
</script>
Hmmm.. not much difference is there? There are the "script" tags that tell the computer browser that we are going to run a script, and which language we are going to use. Then there is the METHOD that tells the browser to print something. And the ARGUMENT contains the characters that are to be printed out. (Okay, okay, ... I said that you didn't have to worry about all of those strange terms yet, but I couldn't resist putting them in there.)
Since both of those scripts are run in the browser on the client side they are almost the same, but want if you wanted to run the VBScript on the server side instead of on the client? It would look something like this:
<script language="VBScript" runat="server">
response.write "Hello!"
</script>
Again, there is not much of a difference. Just a few things that you could have easily looked up.
But what about complex languages that need software to run them? In the next example we will look at the same thing in a language called Perl. Perl actually prints out the html code for a web page when a viewer clicks on a link, but I have left that out so the script won't look too confusing.
#!/usr/bin/perl
print "Hello!";
At first glance this looks dramatically different, but really all of the same parts are there. Think of the first line as the "script" tag. It tells the computer what language we are going to use and where to find the other stuff that it will need to run the script (the /usr/bin/ part.). The only thing that is really missing is a closing "script" tag, but since this would be run through a program used to interpret Perl, we don't need it. Keep in mind that if this were a functioning Perl script it would also have to print the html tags for the page and actually would look more like this:
#!/usr/bin?perl
print "Content-type: text/html";
#generate HTML
print "<html><body>";
print "Hello!";
print "</body></html>";
Using a script to print out html tags is really no big deal. You could do the same sort of thing with JavaScript like this:
<script language="JavaScript">
document.write("<h1>");
document.write("Hello!");
document.write("</h1>");
</script>
*note that I used "h1" tags instead of "html" and "body" tags since a JavaScript would normally be already inside of these tags.
By now you should feel a lot less intimidated and you should be beginning to see that the different scripting languages have much more in common than they do not.
But what about languages that actually run computers, languages that have to be compiled or assembled? As far as a human typing them, they are not too far off from the examples that you have just looked at. The big difference is that after you have finished typing them, you use a piece of software to convert them into a language that a machine can understand. The following is an example of something you might type if you were writing a program to do much the same thing in a language like C++:
#include <stdio.h>
void main(void)
{
printf ("Hello!");
}
Well, I guess that is a little weird, but it really has many of the same elements and I am certain that you can see the similarities. Actually it is closer to a FUNCTION in JavaScript ... but, uhm ... we don't have to talk about that right now.
The short of it is that you do not have to get all worked up over this stuff. Just because you do not have all 22 EVENTHANDLERS in JavaScript committed to memory does not mean that you can't write cool scripts. (Gads! I don't know if I could list all 22 without looking up a bunch of them in a book.) After you have worked with technology for awhile you will learn that there is only one rule to memorize:
As soon as you get something really figured out, some new thing will be invented and everything will change. |