ireckon blog

Blog Entry: What the heck is a HTML? Return of the jargon.

Posted by: Aidan on 6 Aug 2008 @ 11:21 pm Category: Programming and Coding for the Web

My last blog entry was an attempt to describe a few of the technologies that enable we simple humans to work with and use the Internet and WWW. This time I will attempt to describe a few more technologies that enable the operation of the interwebs as we know and love them today, but I will be concentrating more on the software used to build interactive web-sites, as opposed to the networking technologies employed to deliver you web content (like last time).

So, last time I finished off by describing HTML & CSS, which in case you didn't read my last post, are the languages used to define what a web page should look like. Given these 2 technologies, you can go out and create your own web-page. It won't do a whole lot, but if all you want to do is post some information that is unlikely to be updated very often, it might be all you need. Then again, most people WILL want to do updates to their web-site on a regular basis, and continually messing around with and editing HTML & CSS files is certainly not the most efficient way to go about that. There are a host of other technologies that allow web-pages to do all sorts of interesting things.

Client Side Scripting - Before I launch head-long into my description, I should probably define what "client side" and "scripting" means. Scripting essentially means that we give a script, much like that given to an actor in a movie, to a computer which then reads the script and performs the actions it sets forth. So when we say "scripting" in the context of a computer system, what we mean is we're giving the computer a series of things to do. "Client side" means that the scripting is done on the clients' side... which means on the computer you - the person at home - are using. Thus, client side scripting is when a web-site (server) sends a "script" to your computer, and your computer performs the actions in the script. We use client side scripting for things like animating navigation menus, dynamically updating a web page without reloading it, or checking that information entered into a page by the user conforms to certain criteria (e.g. making sure that a phone number contains only numbers, and no letters) before we send it off to the server. In short, client side scripting is mainly used to tell your computer how the page it has just received should behave. The most common client side scripting language, by a large margin, is JavaScript (aka ECMAscript) - in fact you'd be hard pressed to find a large company's web site these days which doesn't include some javascript code in some way - because it is supported by all major web-browser vendors. It interacts directly with the web page in which is it loaded.

Another client side scripting technology is Adobe Flash/Actionscript, which is sometimes used to embed video, audio, and even games into web pages. Where javascript interacts directly with the web page that loads it, flash really only interacts with itself (i.e. it generally doesn't interact directly with or change the page that loaded it).

Server Side Scripting - The other side of the equation is "server side" scripting. Server side scripting is essentially the same thing as client side scripting (i.e. giving the computer a series of actions to perform), except that instead of your computer being asked to perform a bunch of actions, the server which you are receiving your web content from executes the script at the time when you request a page from it. Most of the time, this means that the server is talking to a database server, and asking for particular records it can use to fill out the details in the page it is about to send you.

So as an example, imagine you've used your username and password combination to log into some website you frequent. When you enter your details, there's likely a small amount of client side scripting to check that you did indeed enter a username, and maybe that your password contains enough characters, and so on. Anyway, your web-browser sends your username and password off to the server. The server then takes your username/password and checks to see if it has a record in its database of user credentials which matches the details you provided. If it finds a record which matches, it will usually load that record and display part of the information to you - for instance it might simply load your real name, so that after you login it can say hello in a more personal way (i.e. referring to you by name). If it doesn't find a matching record, it will (or at least in most cases, should) display an error message about the login details being incorrect. Another example is a Google search - you enter a search into the Google home page, your web-browser sends the search term off to Google's server, and it then begins looking for records in its database of websites that match (or are in some way related to) your search term, then send them back to you. You create server side scripts in any number of different languages... there's really no limit to what you can and can't use, so long as you're aware of the limitations of the particular web server you're hosting your pages on. Some examples of commonly used server side scripting languages are PHP (which is nice because it's very easy to find a good web host which supports PHP), Python (which is my personal favorite, because... well, I just like the language itself... I won't go into details why here - maybe that can be the topic of my next post), Perl, Ruby, and Microsoft's .Net languages. For that matter, I've seen people write CGI applications in low level languages like C/C++ - though I don't think I'm out of place calling those people masochists.

Structured Query Language (SQL) - There's actually a special language used in server side scripting scenarios used to talk to the database. Obviously a database is just an abstract store of information, and as such it doesn't respond well to natural human language. It's easy to say "I would like to know the phone numbers of people whose first name is Aidan", and just as easy to understand if you're human... but a computer doesn't know what people are, nor has any concept of a first name. We use SQL to tell the database server that the information it is storing is structured in a certain way, and describe that structure. We can then, operating within our defined structure ask for certain tidbits of information based on other criteria (e.g. The RTA can look up the number plates of all blue 1996 Holden Commodores - assuming that the database is structured in such a way so that the information for a car record contains the number plate, year of production and paint colour). Again, there's a good number of choices when it comes to databases packages supporting SQL - MySQL (which we use here at ireckon), SQLite, MSSQL, PostgreSQL, Oracle, and many many more.

RAMBLE_MODE: DISENGAGE

Back to blog home

Comments

Leave a comment