Between the Code

Have you ever been to Yahoo? I bet you have. Yahoo used to be the #1 search site. It is still very popular, but has expanded to include many different services and functions.

Yet still, the home page isn’t that complicated. There’s quite a bit of stuff there, but it is organized ok and you can easily follow where and what things are. It’s mostly a bunch of links to other Yahoo pages and some ads. In fact, you can print it out onto one piece of paper. Nothing big and complicated, right?

Have you looked at the source or the code? Big difference. If you view the page source and print, you will get 28 pages of html, css, and javascript! That’s what it took to create that simple little page you see. This isn’t even the ‘hidden’ server side code that is run and executed before the web page is sent to your browser. That is probably double the amount.

This is where a lot of confusion has come in, so let me explain a bit. The html, css, and javascript that we are used to and that you see in the source of the web page is all client side code. This means the web server sends it all to your browser and your browser reads and executes it. This is happening all locally to you, the client, so we call it client side code.

Server side code is something like PHP or ASP. This is code that the web server reads and executes on the server before sending anything to you, the client. What this code typically does is makes decisions on what html to use and send, it connects to the database and gets dynamic content to fill in and create the web page, and it may do many other functions that happen on the server side of things. This is all before sending anything to your web browser.

When you look at the Yahoo page, each one of those links and ads and bits of text is stored in a database. The server side code retrieves it and creates the web page to then send to you. Typically, we find that server side code can be 2x - 4x as much code as client side code. Yet, you can create a simple static html page that looks identical to this without a bit of server side code. So why so much code?

You have to remember, that creating static content and pages makes it more set in stone, per se. Every person to visit that page gets the same content. You then have to change it again to get new content. Doesn’t sound too bad, right? Think of this - Yahoo has thousands of pages with new ones added daily and it has thousands of links in it’s database. Do you want to search through it to find the page name to link to? Didn’t think so.

With dynamic code, everything is stored in the database for more easy retrieval. This means the pages are constantly updated as data in the database changes. This makes for much more easily managed web sites with new data and always the best data.

As another example, I worked with someone once to create a dynamic online questionaire maker. Fairly complicated bit of coding for what we wanted to do. The designer spent 4 or 5 hours designing the couple screens we would use. This was the layout and look of the app. We went over it and tweaked it a bit. I estimated it would take another 16 - 20 hours of work to make it all function and make it dynamic. Before we did that, we wanted to show the client to ensure we wouldn’t have a problem later.

The client was very pleased and excited by it. They asked ‘So can we start using it?’. We had to answer No, we needed to make it work. The client didn’t understand, it looked like it was all there. After explaining what we had and still needed to do they reluctantly said they’d wait. When we were completed we went back to show them to functioning application. They were a little bewildered. ‘What did you do, it still looks the same?’ We had a hard time explaining that yes, it would look the same as what we did was add the server side code to make it all work.

So, server side code doesn’t show and may be hard to tell what it does. But when web pages are taking 28 printed pages of code, you can bet the scripting server side code is quite extensive. If you can see a difference, the programmers didn’t do as well as they should have.

Another interesting point, did they really need that much code for the Yahoo page? Arguably not. Much of the code is CSS and looks like some browser specific stuff but also some things added after other stuff was already there. There may have been good reasons for what they did, but it’s usually best to try to limit the amount of browser specific code you get.

One of the difficulties of the web is it’s statelessness. What does that mean exactly? The web was designed to show text content with some pictures. The web part of it was using hyperlinks to allow people to easily navigate between these web pages. At the time, everything was static, non-changing content. Basically web pages we treated like magazine articles.

That has all changed. Now, almost every web site is dynamic with programming and database content. The problem comes in trying to do things like shopping carts or logins. When your web browser requests a web page, it connects to a web server and asks for the page. The web server sends the page and closes the connection. When you then click a link to go to a new page, it again connects to the web server and gets the page. There is no mechanism for the web server to know that this is the same person that asked for page1 a couple minutes ago. So when you have a shopping cart, you are in trouble. There is no way for the products page to know about the items in your shopping cart. The pages can’t communicate between themselves to store information.

To work around this problem, we need to use programming. In this case, we would use SESSION variables. A variable is a container (think of it as a box) that stores information. Think of it as a box. A variable called Last Name would have ‘inside’ your last name. You can change what is ‘inside’ the variable, hence the name variable. SESSION variables are specific variables with a special function. These variables are set to contain information, but they also are associated with the particular person and browser that was on the page when it was set.

So, when you go to a product page and choose a product to add to your cart, the server does several things. First, it talks with the browser to see if a SESSION variable with the shopping cart id is already present. If not, the server makes a new SESSION variable with the shopping cart id and associates it with your browser. Then, whenever you go to the view cart page, the server sees which browser is there and finds the associated SESSION variable that has the shopping cart id. It then knows what id to look in the database for the find all the products in that shopping cart.

SESSION variables also work similarly when you login to a password protected area. An id gets set as a SESSION variable so the computer knows that you logged in successfully and it can use the id that is stored to pull only your information from the database.

SESSION variables are generally invisible to the user and the code doesn’t show up on the web page. It is a fairly effective way to keep some sort of information about you between pages. Once you close your browser, the SESSION ends. The next time you are on those pages, a new SESSION variable with a new id is created.

Asynchronous Javascript or Ajax is one of the hottest buzzwords in web development. Instead of boring you with the technicalities, I thought I would take a minute to show an example of how we recently used Ajax on an order page.

A client had an order page where they took orders for three different types of fuel oils and each type had different data we needed to collect to process an order. Including the options for each of these three types on one order form made the form lengthy and confusing, so we used Ajax to change the form on the fly based on which product the customer was ordering.

First, on the form itself, the select menu for fuel type looked like this:

The “onChange” parameter of the select menu calls a Javascript function makeRequest with the value of the option selected from the menu.

makeRequest looks like this:

function makeRequest(type) {
var textType = ‘’;
if (type == 1)
textType = ‘heating’;
else if (type == 2)
textType = ‘gasoline’;
else (type == 3)
textType = ‘diesel’;

// browser checking to create ajax object
if (window.XMLHttpRequest)
http_request = new XMLHttpRequest();
else if (window.ActiveXObject)
http_request = new ActiveXObject(”Microsoft.XMLHTTP”);

// format request
url = ‘proc.ajax.php?type=’ + textType;

// send and procss resonse
http_request.onreadystatechange = updateForm;
http_request.open(’GET’, url, true);
http_request.send(null);
}

function updateForm() {
if (http_request.readyState == 4) {
if (http_request.status == 200)
document.getElementById(’dynamicForm’).innerHTML = http_request.responseText;
else
alert(’Error’);
}
}
}

This code takes the value from the menu and converts it to a string (heating, gasoline, diesel), creates an Ajax object based on the browser being used, then sends the request to another page that formats the response.

This line :
http_request.onreadystatechange = updateForm; tells the function to call updateForm when a response arrives from the page we sent the request to.

updateForm waits until it receives a “done” (readyState = 4) response and, if the status is 200 (indicating success), this line: document.getElementById('dynamicForm').innerHTML = http_request.responseText; dynamically places whatever was returned into the form (in the ‘dynamicForm’ division).

The page that handles the Ajax request looks like this:

$type = $_GET['type'];

switch ($type) {
case 'heating' : echo $heating; break;
case 'gasoline' : echo $gasoline; break;
case 'diesel' : echo $diesel; break;
default : echo ''; break;
}

This PHP code simply defines a table layout for each of the three fuel types, then prints the correct text based on the querystring value (which we specified in the Javascript here: url = 'proc.ajax.php?type=' + textType;). This text is what the Ajax object uses as it’s response to the request and what is then used to update the form based on the fuel type chosen from the menu.

While this certainly could have been accomplished by including code for each version of the form in a Javascript array then switching between them based on a selection from the menu, the Ajax version not only reduces the page size, but separates the functionality so updates to the form (like adding a new fuel type) are much more easily made.

Also, had this form required a few dozen different layouts based on multiple user selections, managing that concurrency on one page would have been a nightmare. With Ajax, simply defining an Ajax call for each dynamic section would allow individual sections of the form to take care of updating themselves without needing to know what’s happening in the rest of the form.

We recently had to track down a problem where text and images were appearing smeared under certain circumstances in Internet Explorer. The smearing happened in a frame when the the content in the frame is scrolled vertically.

After much experimentation, we discovered that removing the DOCTYPE on the page corrected the problem. There’s almost no documentation of this problem on the web, so I wanted to get this information up here in case anyone needs a fix for this issue.

Also, this is a good opportunity to discuss DOCTYPE and what it means.

Document Type Declaration (DOCTYPE) specifies to what standard the html markup on your page conforms. As non-standard ways of writing html are being deprecated, adding a DOCTYPE header to your html pages allows you to use automated validation tools to test how strictly your page complies with web standards.

Other than markup validation, the most pervasive effect of DOCTYPE involves maintaining backwards compatability with pages designed for older browsers. Many (if not most) of these pages were created before web standards became widely followed and before Internet Explorer had much competition in the browser world.

In versions of Internet Explorer prior to version 6, bugs were present that caused content in pages to display differently than was specified in web standards and differently than in other competing browsers. Because IE had such a monopoly on the browser market at the time, web designers tended to test their pages only in IE and their designs were necessarily dependent on the (improper) rendering these bugs caused.

When Microsoft released IE6, which corrected many of these bugs, they knew that millions of web pages designed around the buggy versions of their browser would now break in IE6. To combat this, IE6 included two rendering modes - standards compliant mode and “Quirks” mode.

In a nutshell, Quirks mode is the rendering mode that included the pre-IE6 bugs and standards mode is the modern web standards rendering. But, Microsoft needed a way to determine in which mode to display a website as each was incompatable with the other.

They settled on DOCTYPE. As DOCTYPE is used to declare to which web standard a page should be validated against, Microsoft assumed that web designers who included a DOCTYPE would be following more modern design practices and therefore their pages could safely be displayed in web standards mode.

For those pages without a DOCTYPE, it could be assumed that they are either legacy pages from before web standards became widely followed (and therefore reliant on the “quirky” behavior of older browsers) or created by designers who were following older design practices and also likely reliant on these bugs.

So, include a DOCTYPE (of any kind) and trigger standards mode or leave one out and trigger Quirks mode.

Somehow, something in IE standards mode (before IE7, display is normal in IE7) triggers this page blurring effect…any ideas?

I’d like to talk about a bit of security programming.

Let’s look at a contact form. This is usually a form that the user fills out to communicate with the web owner. You can have email, comments, and possibly other types of fields to fill out. When this is submitted, the information is then emailed to the designated person.

One problem that has arisen from these types of forms is that a hacker will get the html of the form and save it on their local machine. They then write a script to use that to send out spam email. If it is an especially bad form, it will store the email to send to in a hidden field. All the hacker has to do is change that email in the script he creates a loop the script. They then read a list of emails to substitute in there each time. So essentially, this list of people gets a spam email that is using your form and mail out script. So the person think you are spamming them!

To help get around this, we can add some security code to the script. First, we don’t put any emails in hidden fields on the form. Then, the only place the emails get sent are in the explicit emails in our code.

Next we add some code at the top of the page that has the email code. This will check to ensure that the information was submitted from the proper place. On the first page, when you click submit, it passes to page 2 the name of the domain and web page used to submit the information. We can add security code to check that the submitted information is from the correct web domain (and not a hackers computer) and is the correct page name. This helps ensure that we only work with valid information.

This is just one of the security measures we are taking with web projects.

Recently wrote a PHP script that will transfer login data from the Xoops content management system to Joomla and thought I would post it here in case anyone is converting their site to Joomla from Xoops.

First, export both login database tables (xp_users for Xoops and jos_users for Joomla in the install I was working on) and import them into a local installation of mySQL. If you don’t have access to a local installation of mySQL or have no users set up in Joomla yet, you can run this script on your live database tables but be sure to back up any data you can’t afford to lose.

Documentation in the script shows what’s being done - the conversion I was doing was fairly simple (no custom groups, special logins, etc.) but, if you’re doing something a little more complex, this will hopefully give you a good place to start.


< ?php
// Export XOOPS login information to Joomla
mysql_connect("localhost", "“, ““);
mysql_select_db(”“);

$sql = “INSERT INTO jos_core_acl_groups_aro_map (group_id, aro_id)
VALUES ($gid, $id)”;
mysql_query($sql);
}
?>


This little article isn’t going to show in depth code, but is an important part of development.
Most people don’t realize what it takes to test an application properly. Let’s use a small example.

We have a members area with a login. A user can log into their account by typing in their username and password. If they type it wrong, they are told they can’t get in and can try again.

To test this, we have to define the scenarios that could occur and test for them. For the above example, some scenarios are:
1 - a user types a correct username and password and gets in
2 - a user types an incorrect username but correct password
3 - a user types a correct username but incorrect password
4 - the user hits the submit button without typing anything in
5 - the information typed in is a string of malicious code and not a real username/password
6 - the user types a correct username, but has a space at the beginning
7 - someone tries to pass information to the php page to check the login, but they didn’t use the actual login page
8 - someone copied the login page and is trying to login using it maliciously

There are probably more, but these give you an idea of the things we need to test. And each item may need tested more than once to account for slight differences or to test a sub-scenario. Along with that, we need to make sure that it is accurately connecting to the database and not just saying ‘Yup, it’s ok’, we need to make sure if logged in correctly everything gets set properly. The error messages should appear and be appropriate to the error.

PLUS - now we need to test each of those scenarios on IE and Firefox. Maybe we need to test on Mac safari also. What about needing to test it on AOL browser?

If there is a problem we have to identify the actual problem to get it fixed. Then guess what, we need to test it all again! Not just the part that had an error, but everything. Why? Because the fix we just did may have broken something else.

Ugh. This is just for a simple login. When you start getting more complex information and interactions between various database tables, the job of testing can become even more complex.

We may fix 25 bugs in a project before it even gets to an end user. They may be as simple as an error message is appearing white instead of red. But it’s a bug that needs fixed since we missed it when we originally coded. This doesn’t mean the code is bad or the programmers aren’t good. Everyone programs with some bugs. We’re human. You don’t even want to know how many bugs there are in Windows or Mac OS that are known and not fixed.

The point is, testing is a very integral, though time consuming, part of the whole development process.

This seems like such an old topic, but it’s still one that many don’t understand. It’s also a good one to use to start this blog off.
A mouse rollover is when you move your mouse pointer over graphics or text and it changes somehow to indicate that you are hovering over it. This happens a lot in navigation buttons where it gets highlighted before you click it.

Let’s take a simple example of a button. Most buttons are images and the code looks like this:
<img src=”images/imagename.jpg”/>
If you don’t normally see code, stay with me. It’s fairly painless.
All this tag says is that it is an image (img) and the image filename is imagename.jpg and it is located in the images directory.

Now, to make the effect, we need to add 2 parameters. These are additional instructions to tell the computer what to do when the mouse moves over the image.
The first is onmouseover. This gives instructions on what to do when the mouse moves over the image. Most of the time you will use a style that you want to switch to or javascript that will create the effect.
So now we have something similar to
<img src=”images/imagename.jpg” onmouseover=”this.style=change”/ >

The above code changes to a different style. The last part of this is onmouseout. This gets run when you move the mouse away from the image. Usually this is for resetting to what things were originally. Why do we need to do that? Because we changed it and we have to tell the computer what to change it back to or it would just leave it changed.
So now we have:
<img src=”images/imagename.jpg” onmouseover=”this.style=change” onmouseout=”this.style = oldstyle”/ >

This just changes it back to the old style, assuming that’s what we used before we hovered over the image.
Take a look at some code for rollover effects and you will see this. To view, find the page you want and go to the view menu and then choose Source.

Examples:
Mind Architecture - this is my old site. The nav on the left has a nice rollover effect. This is achieved totally with text, html, and css. You can do more advanced functionality also.
Mohawk Valley Fine Arts - this is also a text, html, css rollover. The difference is that these ‘buttons’ are just css and text and not buttons at all. This is great for doing dynamic web sites where the nav may get updated.
Hasenstab Architects - This site uses rollover buttons but instead of changing the button to looking like it’s pressed or changing color, it has a little graphic appear next to it. This nav uses images for the regular and the mouse over positions.
Mobility Works - a more conventional use of images for mouse rollovers.

Good luck!

This blog is meant for web designers and developers who would like to understand a bit more about non-graphical things. Like databases and scripting. We’ll try not to go into too much detail, but explain how some bit of code is working. Some topics may be of no interest and others you’ll want more. Please let us know if there is anything more we can write about in this.