Roger L. Main

This article assumes that you either have a basic knowledge of HTML or that you have read my series of articles on basic HTML. If you're "jumping in the deep end" then I say "Don't jump!" Follow the links provided by Professionals in Pajamas to go back to the basic HTML tutorial before reading this.

Try putting this into your HTML script:

<script>alert ("Hello World!");</script>

It doesn't look like much and it doesn't do much - when you open the page you'll see a window pop up with "Hello World!" written on it - but it's the first step in a much larger world: the world of web page programming. The next series I'll be delivering will talk about web page programming - making your web page do more than just show something - it'll do something. This article serves as an introduction to some fundamental concepts you'll need before you can take the plunge into this exciting and rewarding area.

The typical language for web page programming (a.k.a DHTML or Dynamic HTML) is called JavaScript. It's the most widely accepted amongst the various browsers out there. There is also VBScript, PascalScript, PerlScript and a bunch of others, but these usually require a browser plug-in to run (VBScript is an obvious exception - it's built into Microsoft's Internet Explorer web browser). The next few articles will be looking at how to put some razza-matazz into your web pages by making them dynamic.

First, a comment on tags. Note that, in the example above, I've included my JavaScript statement between <script> and </script> tags. These are required around any scripting content you wish to include. This is the shorthand version and implies the use of JavaScript. I could just as easily have said

<script language='javascript'>alert ("Hello World!");</script>


	or even:


>script language='vbscript'>msgbox ("Hello World!")</script>

Although the "language='javascript'" part is not necessary if you're writing your dynamic content in JavaScript (it is if you're using a different scripting language) it's usually a good idea because it lets anyone who is reading the script know that it's definitely JavaScript that is included and not something else. Furthermore, if you want to branch out into another language, then you're already in the habit of saying which language it is.

It's also possible to include your JavaScript in a seperate file. For this, create a seperate file (usually with a .js extension for Windows computers, but not prescriptively) and include your code without any encapsulating tags, for example:

alert ("Hello World!");

would be in file all to itself. Then, in your HTML page you would have the following:

<script language='javascript' src='helloworld.js'></script>

Note, that the closing tag is still required even though there's nothing between them. Can you have something between them if you're including a source (src)? Sure you can, but don't expect the code between the tags to actually run. By adding "src='helloworld.js'" you tell the browser that the code is in the file NOT between the tags. However, you can capitalize on this and use the space between the tags for comments, such as this:

<script language='javascript' src='test.js'>

 This file includes a "Hello World!" dialog

</script>

That covers the HTML portion of dynamic scripting. Now comes another very important concept: JavaScript, despite its name, is not Java. Java is a powerful programming language in its own right and while it shares much of the syntax of Java it is its own animal. Don't claim to be proficient at Java just because you're proficient at JavaScript. That just ain't so.

Probably the most important concept to understand when delving into JavaScript programming is precisely that - programming. The name may be JavaSCRIPT, unlike HTML, which truly is a scripting language, JavaScript really deserves the moniker of Programming Language, because what you are doing really is programming - you are defining the behaviour of the computer based on a series of conditions and commands. This, by definition, is programming.

The next concept (almost as important as the previous one) is the concept of Object-Oriented Programming. If you're about my age *undisclosed* then the home computer was probably very new when you went to high school. Your school probably debated for years the benefits of actually having a computer in the school. And when your school did finally break the budget to purchase a brand new Apple II computer they probably offered courses in basic programming (I mean "simple," not programming in the language BASIC - although they probably did that, too).

It may even have been the case that your teacher in programming was only half a chapter ahead in what he was teaching, because it was so new to him/her, too! But I digress. The point is that programming then and programming now are two entirely different animals. Back then programming was Procedural, today it is Object-Oriented (although some languages allow a hybrid of both, which is my personal preference). Back then you used line-numbers. Today programmers will muse and say, "Oh yes, I remember those."

Ever seen this statement (from the old Apple II):

10 PRINT "HELP, I'M GOING CRAZY!"
20 GOTO 10

What does this look like in JavaScript?

do {
  document.write ("Help, I'm going crazy");
} while false;

Of course, I don't recommend you ever try this - it'll send your computer into a frenzy and you'll never see anything actually written in it. False is false and is never true and, therefore, the script interpriter will never leave the loop - not even long enough to actually render the text into the browser. Eventually you'll run out of memory and get an error. But the point is, using loop structures like this we can escape from the mindset of line numbers.

How about objects? An object is something around you like... a stapler (I chose that because there's one right in front of me as I write this). How would you describe it? Well, it has attributes (size, color, number of staples) and a function (distributes and bends staples into pieces of paper). The staples themselves are objects. They have attributes (size, color) and a function (holds paper together). That's the concept of object-oriented programming (or oop, as it's called in shorthand). Prior to oop, you would "program" a stapler something like this:

10 DIM STAPLERSIZE
20 DIM STAPLERCOLOR
30 DIM NUMSTAPLES
40 GOSUB 100

100 REM USE THE STAPLER
  ... (code to do the stapling)
120 RETURN

Note: REM is the old line-number basic command for "remark."
Anything you want to put there - it doesn't affect the program.

Each attribute would have its own descrete variable (programming concept: variable - a holding place of a value where that value can change) for each attribute and a seperate piece of code where you do the processing. You would "pass in" the variables you want to use. Here's an example using Pascal - a common teaching language because of its simple syntax. Or, rather, pascal pseudo-code (programming concept: pseudo-code - code that gets the point across but is syntactically wrong and won't run) - anything between { and } is a comment:

var  numstaples: integer;
     mypaper: {some paper variable type thingy};
     mystaple: {some staple variable type thingy};

procedure staple_something (var staple_count: integer; 
	 var paper: {paper thingy};
     var staple: {staple thingy});

begin
if (staple_count > 0) then
  begin
  paper := staple;
  numstaples := numstaples - 1;
  end
else
  writeln ('out of staples');
end {staple_something};

begin {main program}
staple_something (numstaples, mypaper, mystaple);
end.

Note that I had to tell the "staple_something" routine that I want it to use numstaples, mypaper and mystaple to do the stapling. Each is an item independent of each other and independent of the over concept of stapler. I can have numstaples without even having a stapler or staples (an insane idea in the real world, but believe it or not, in traditional computing this is how it worked).

Well, object-oriented programming takes away that ambiguity. In oop I define a stapler and, therefore, a count of how many staples I have *cannot* live independently, just as it can't in the real world. Again, pascal pseudo-code but to get the concept across, here is a stapler in oop:

type  stapler_type = object
        num_staples: integer;
        staples: list of staple_type;
        procedure staple_something (paper: paper_type);
      end;

var   mystapler: stapler_type;
      mypaper: paper_type;

procedure stapler_type.staple_something (paper: paper_type);

var  astaple: staple_type;

begin
if (num_staples > 1) then
  begin
  astaple := staples.remove_one;
  paper.add_staple (astaple);
  num_staples := num_staples - 1;
  end
else
  writeln ('out of staples');
end;

And then there's the clincher, in the main line of the program (programming concept: main line - the part of the program that's executed first and is the starting point for the computer):

begin {main line}
mystapler.staple_something (mypaper);
end.

Whew. This is a difficult concept to get your head around, so I hope I haven't lost you. The features to note between the two different versions: firstly, we actually defined "stapler" in the second version. In the first version it was a nebulous concept. Second, we told the stapler to do the stapling, rather than tried to describe it in abstract terms, a la the first version. Less obvious, but nonetheless important, the first version only allows for one stapler. If we wanted more than one, we would need to have a seperate numstaples, staplesize etc for each one. In the second version, we only need to define something as staple_type and it has all those attributes - they come with the package. This is referred to as an instance of a stapler (oop concept: instance - one of a particular type of object).

Now, by this point you're probably asking yourself, "why is he spending all this time talking about oop - I thought we were learning JavaScript?" That's a valid question. Firstly, there's more to oop that what is displayed above - this only discusses one concept of oop called "Encapsulation" (oop concept : encapsulation - the co-existence of data and code in a descrete package). There's also "inheritence" (making a subset of an object, for example you may have object "vehicle" which could be a bicycle, car or train. They all have a similar attribute - wheels. However, from this overall concept you could define a subset called "car" which has, specifically, four wheels and carries passengers rather than subset "train" which has multiple wheels and carries coal). The point is you would only have to define "wheel" once and all the subsets get it. This is inheritence - they inherit the attributes of the parent concept.

There's also "polymorphism" which means one object looks like another to an independent process - a carwash can wash cars, but it can also wash trucks and even motorcycles (assuming the rider doesn't mind getting wet). The carwash object doesn't care so long as it's of type "vehicle." That's polymorphism.

The second point as to why this is relevent to JavaScript is the most important. In JavaScript everything is an object! Well, almost everything. There are some independent processes (such as the "alert" function we used earlier) and there are some independent variable types (such as an integer or whole number) but those are pretty few and far between. JavaScript defines and manipulates the behavior of your browser, which is an object (no, really. The overall object in JavaScript is called, surprise, browser). So oop is an integral concept in JavaScript, so you really should get used to it now or you'll be completely lost later on.

I think that's enough to chew on for now. You may want to do some research of your own. If you want to get a feel for what the JavaScript objects available are, then have a look at Microsoft or Netscape's web pages where they go into more detail. Next month we'll actually start writing some JavaScript code.