Web Development Intensive

AJAX is an acronym that stands for Asynchronous Javascript And XML.  It refers to a specific feature of the browsers’ implementations of Javascript that became popular in the first few years of this century because it provided a way in which web pages could load content on demand in reaction to a user’s actions, rather than preloading all content with the initial page load, as had been the norm previously.

Many people in the web industry conflate the terms AJAX and dHTML.  Since you are taking this class, you should know the accurate meaning of each of these terms, even if you choose not to stick to the correct meanings when conversing with the ignorant and incorrigible masses.

dHTML

Since Javascript was first introduced into Netscape Navigator in 1995, people have been using it to change the content of web pages.  In other words, long before AJAX was even possible, there was dHTML.  Dynamic HTML is the technique, which we have already seen, of using Javascript to change the content of the page dynamically.  Most typically, this change is in response to a user’s action, such as a click, a mouseover, mouseout, or some other action that changes the appearance of the page in some way.  Often, these changes are simply showing and hiding various parts of the content, or changing the styles associated with some of the content.

By preparing Javascript, CSS, and XHTML in just the right way, a website maker can make a page seem to be dynamic and responsive to user actions.  dHTML refers to this use of Javascript, in combination with CSS and XHTML, to make a page seem dynamic and responsive.

People don’t use the term dHTML very much anymore, although the dHTML techniques are used more than ever.

AJAX

AJAX refers exclusively to the technique in Javascript whereby Javascript code on a page makes a request to the server without requiring a reload of the entire web page.  As we have discussed the client/server relationship, the HTTP GET and HTTP POST methods, persistent data and passing data, we have spoken as if a request to the server is one and the same as the loading a whole web page in the browser.  Now you know that there is a way to make requests to the server without requiring the reload of the entire page – it is called AJAX.

After an AJAX request is made from the Javascript code running on the client to the server, the server may respond, as it usually does to any request.  The Javascript code that made the request often waits [asynchronously] for that response.  Once the response is received from the server, the Javascript code on the client then updates the content of the page dynamically using standard dHTML techniques depending on exactly what response it got back.

People often [inacurrately] use the term AJAX to mean any dHTML, regardless of whether it actually involves a request to the server.  The term, AJAX, has been usurped by marketers to indicate any kind of dynamic content.

Conceptually, making an AJAX request is identical to any other request to the web server.  The Javascript code makes the request using either HTTP GET or HTTP POST.  The client can pass data to the server along with that request, or not.  The server can process that request using PHP or some other server-side language, read any data that was passed, do some business logic, and respond appropriately.

According to how AJAX was originally conceived, the server was supposed to respond with some XML code that the browser thean parsed.  Practically-speaking, the browser is not especially good at parsing XML, so receiving a response in XML is more work than it’s worth.  Today, having the server respond with XML is the exception rather than the rule, although it is still done.  However, these days the server is programmed to usually respond either with an XHTML snippet which is then dynamically output on the page by the Javascript script on the client, or the server responds with a Javascript code snippet of its own which is then run by the client.

JQuery

Naturally, Internet Explorer handles making AJAX requests differently from Firefox and the other popular browsers.  Once again, JQuery solves this problem by providing a set of functions that normalize the browser differences for us.  While you can, of course, use the native Javascript AJAX methods to handle the asynchronous requests to the server, I strongly recommend that you use JQuery or another Javascript framework instead to make your code more reliable across browsers, and to keep it simpler and easier to maintain.

Let’s say that we are building a social network.  What we call a social network is a site that has a bunch of users, and those users can decide to be “friends” with any other user.

You can view this example live here.

The Views

There will be four pages that the user sees:

• Register – where new users go to register to become users
• Login – where registered users go to login
• Home – a page that shows a list of the logged-in user’s friends, and a list of people who are not his/her friends.
• Friends’s Profile – a page that shows details about another user

Each “page” requires a View in order to be displayed to the user in the browser.  Anytime there is something displayed to the user, we should know that there is at least one View used to create that interface.  So we can say that there are four Views in this application.  In our example application, the files that contain the templates for these Views are:

• views/register_view.php – the template for the Register page
• views/login_view.php – the template for the Login page
• views/index_view.php – the template for the Home page
• views/profile_view.php – the template for the Friend’s Profile page

The Controllers

• We only want to let a user go to the Login page if they are not already logged in.  If they are already logged in, we need to redirect them to the Home page. Anytime we have a script that performs some logic like this, we should consider it a Controller.
• Likewise, a user should only see the Register page if they are not already logged in.  Again, this logic is handled by a Controller.
• Assuming a user is not already logged in, when they enter their username/password in the form on the Login page and click the submit button, there has to be some script that performs the logic to compare the username/password data the user entered in the Login page to the user data stored in the database. If the username/password matches what is found in the database, this script has to let the user in to the site.  This logic is the job of a Controller
• Likewise, when a user fills out the Register form and clicks submit, a script has to check to make sure they entered a valid username/password, and then if everything is ok, the script has to somehow create a new row in the database that stores that username/password.  Then the user should be redirected to the Home page.  This business logic is the job of a Controller.
• The Home page needs to check to make sure the user is logged in.  It then needs to retrieve the list of friends of the logged-in user, the list of people who are not friends of the logged-in user, and then display that data to the user.  The decision of what data to retrieve from the Model, and the job of then forwarding that data to the View which displays the interface, is the job of a Controller.
• The Friend’s Profile Page has the same type of Controller as the Home page.  Data must be retrieved from the Model, and then that data must be properly inserted into the View for this page.  So a Controller must be present to take care of this.

The Controller scripts that I have created for this application to handle these tasks are:

• authenticate.php – handles all tasks related to Login and Register functionality
• index.php – handles all tasks related to viewing the Home page
• profile.php – handles all tasks related to viewing a Friend’s Profile
• friendship.php – handles all tasks related to adding/removing friends

The Models

As should be clear by now, Models are necessary to handle the parts of this site where direct access to the database is needed:

• compare any username/password combo to those already stored in the database (necessary for the Login and Register pages)
• create a new user in the database (necessary for the Register page)
• create/delete friend associations in the database (necessary for the Home and Friend’s Profile pages)
• get a list of a user’s friends (necessary for the Home and Friend’s Profile pages)
• get a list of people who are not a user’s friends (necessary for the Home and Friend’s Profile pages)

The Model scripts that do these tasks are:

• models/User.class.php – handles any tasks related to creating, reading, updating, or deleting users
• models/Authentication.class.php – handles any tasks related to logging in or registering a user
• models/Friendship.class.php – handles any tasks related to friendships between two users
• models/Santize.class.php – handles any tasks related to data sanitization

To be consistent and complete, I have added the standard CRUD functions to each Model script, as well as the functions which handle each of the database-related tasks listed above.

It’s object-oriented

You can see that I have created seperate class files for each Model.  I am combining MVC architecture concepts with object-oriented programming techniques.  I have created classes for each type of “object” or “entity” that I think may conceptually need specific actions taken on it.

Object oriented programming is a seperate concept from MVC architecture.  But I have used this example to exhibit both.

It uses a home-brewed framework

You can see that I have organized my code in a specific way.  All Model files are contained in the models/ folder.  All View files are contained in the views/ folder, and all Controller files are contained in the root folder.  Javascript files would go in the scripts/ folder.  Style sheets are in the styles/ folder, and database connection info is in the dbinfo/ folder.

One of the core features of a so-called “framework” is a clear organization of the files involved in a project.  So you could call this organization that I have come up with a sort-of home-brewed framework.  It is very simple, and crude, but it is effective at helping organize our MVC object-oriented application.

The popular frameworks that PHP developers use, such as Zend, CakePHP, Symfony, and CodeIgnigter, do much more sophisitcated things than just seperate your code into folders.  So I doubt my framework will become the next big thing.  But it is useful for our purposes nonetheless.

What the user sees

It’s important to note that the users will be completely oblivious to our use of an object-oriented MVC architecture.  This is a good thing: you don’t want users to have to worry about how a site was developed.

When a user goes to the Login or Register pages, they will see the address authenticate.php in the browser address bar.  This is the Controller script that we know handles all tasks related to logging in and registering.  This controller figures out whether the user wants to see the Login Page or the Register Page, and loads up the appropriate View for either page.

When a user goes to the Home Page, they see the address, index.php.  This, as we know, is the Controller file for the tasks related to the Home page.  This Controller calls functions in the Model that get the data related to the Home page, and then this Controller loads up the View file for the Home page, which displays this data nicely.

Similarly, when a user goes to a Friend’s Profile page, they see the address, profile.php in the browser’s address bar.  This is the Controller file for all tasks related to viewing the Friend’s Profile page.  This script gets all the data by calling functions in the Model, and then includes the appropriate View file to display that data.

Favicons are the little icons that show up in the address bar of the web browser for some websites. For example, the favicon for blogger.com is the little orange square with the B in it.

Favicons are totally optional, but a well-designed favicon can add a slightly more sophisticated feel to your site, even though the user may not ever realize it is there.

So of course, you will want to create a favicon for your own sites. Favicons are 16 pixels wide and 16 pixels tall.  They are saved in a special .ico image format that is not natively supported by graphic design programs like Photoshop. This article has a good explanation of how to download a Photoshop plugin that lets you save favicons in .ico format using Photoshop.

If you don’t have Photoshop, you can still create favicons by using a variety of website services that convert standard .jpg, .gif, or .png image files into .ico format. For example, here is one such site.

To use your favicon once you have created it, make sure the file is named favicon.ico, and put it in the root folder of your website. Then add the following code into the <head> of your XHTML code:

<head>
  ...
  <link rel="shortcut icon" href="./favicon.ico" />
  ...
</head>

Now that you know all the basic techniques of web development, it’s time to start thinking about aesthetics. One the most obvious aesthetic choices you can make on your site is what domain name you choose, and what you call the file names on that site. Domain names are something I can’t help you with, but the rest of the URL after the domain name, including the folder and file names, is something I can help you beautify.

This is an advanced topic, but one that can provide polish to your sites if you are comfortable with all we have covered so far.

The problem: ugly URLs

As you know, depending on what we call our files and how we use the query string to pass data from one page to another, we sometimes end up with URLs that look like this:

http://onepotcooking.com/index.php?post=19&view=rss

But you might rather have URLs that look like this:

http://onepotcooking.com/rss/post/19/

And actually, search engines sometimes prefer more descriptive URLs, so they can more easily determine what a page is about:

http://onepotcooking.com/rss_feed/why_urls_should_be_pretty.html

But you don’t want to change the structure of your folders and file names, and change the entire way you use the $_GET, $_POST, and $_REQUEST variables in PHP just to make the URLs pretty. When you’re coding the site, you’re usually thinking about functionality and getting the job done, not aesthetics.

The solution to URL woes: mod_rewrite

Apache, the most popular software used by web servers to handle the requests and responses for web pages (and the software used by our class server and most other UNIX web servers) comes with a module called mod_rewrite that is used for creating custom URLs.

mod_rewrite lets you publish fancy URLs like:

http://onepotcooking.com/isnt_this_a_prety_url.html

But have them actually get converted internally into ugly URLs like this, without the user ever seeing it:

http://onepotcooking.com/process_something.php?id=1884&to_do=something&this_is=ugly

You will be able to use the fancy URLs for any links to your pages, but your folders, filenames, and PHP code will not have to change, so long as you use mod_rewrite correctly.

Rewriting vs. Redirecting

This process of having fancy URLs that get internally converted by the server into ugly URLs is known as URL rewriting. With a rewrite, since it only happens internally in the server, the user only ever sees the fancy URL. They will never see the ugly URL in the browser address bar.

However, the term redirect is generally used to refer to the technique where client, meaning the web browser, handles the redirecting. In the case of a client-side redirect, the user can see the final destination URL in the browser’s address bar after the redirect occurs. So they will ultimately see the ugly URL clearly in the address bar of the browser.

Another look at the client/server request/response relationship

To understand how mod_rewrite works, it’s important to understand where it fits into the whole request/response relationship. Here’s a very broad overview of the just relevant steps of what happens when a client requests a file from a server:

• a user tries to load a web page in the browser (whether by going directly to a URL, clicking a link, submitting a form, or making an AJAX request)
• the browser sends an HTTP request (either GET or POST) for the file to the server.
• the server receives the request, and launches Apache’s request handler
• Apache tries to figure out how to respond to the request
• Apache first checks mod_rewrite settings to see if it should do any fancy processing of the URL of the file that the user is requesting
• Then, if Apache determines that the requested file is a PHP script, it launches the PHP engine and sends any data that was passed along with the request to the PHP script that the browser requested
• The PHP script runs and sends its output back to Apache
• Apache sends a response to the web browser. The response contains an HTTP status code indicating some information about whether the request was processed properly or not, as well as any content that was output by the requested file, regardless of whether it’s a PHP script, HTML file, CSS file, Javascript file, or any other type of file.
• The browser receives the response from Apache, and figures out how to display whatever content it received back from the server to the user.

As you can see, the mod_rewrite technique we will be discussing that allows sites to use fancy URLs will occur after the server has received the request from the browser, but before it has passed that request on to the PHP processor. It will be written in language that Apache can understand, not in PHP, since when it is processed, the PHP engine hasn’t even been launched yet.

Apache configuration files: httpd.conf and .htaccess

When a user requests a URL like this:

http://onepotcooking.com/spring2010/test.php

the Apache server checks two sets of configuration files to see whether it should do something fancy with that URL.

First, Apache checks its main configuration file, called httpd.conf, which is usually buried somewhere obscure in the deep recesses of the server filesystem. Httpd.conf has global settings that apply to your entire site. If you have a shared hosting plan for your site, which most of you will do, you do not have access to this file.

After it has checked httpd.conf for any relevant settings, Apache then checks the directory-specific configuration files called .htaccess, which have settings that apply only to specific folders.

With the example URL above, Apache would have to check for the existence of either of these two .htaccess files:

/.htaccess
/spring2010/.htaccess

Since the requested file is nested inside the spring2010/ folder, which is inside of the root / folder, either of those settings files could have an effect on how the request for the file is handled by the server.

We will be focusing on settings in the .htaccess files since these are the ones you will always have access to, regardless of your hosting setup. However, the same URL rewriting techniques will be applicable to settings in the httpd.conf file, with slight modifications.

How to use .htaccess files to rewrite URLs

Rather than rewrite an entire tutorial on how to rewrite URLs (which I initially started to do), there is an excellent tutorial already written which covers all the basic types of rewriting you are likely to do:

http://corz.org/serv/tricks/htaccess2.php

Note: Although I don’t think it’s clearly described on this site, all of the example code written there is meant to go into a file called “.htaccess” located in the root folder of your project. So if your project is at http://onepotcooking.com/johnhancock/final_project/, you should create an .htaccess file located at /johnhancock/final_project/.htaccess, so you can create fancy URLs like http://onepotcooking.com/johnhancock/final_project/this-is-a-fancy-url.html

In other words, fancy URLs only work at the level at which you put an .htaccess file. If you want a fancy URL like http://onepotcooking.com/this-is-a-fancy-url.html, you need to put an .htaccess file in the root folder of the server, /.htaccess.

I highly recommend you read that otherwise well-written document linked above if you wish to use fancy URLs on your own sites.

An example page

I have created a single example PHP script which can be accessed by a number of fancy URLs by taking advantage of rewriting rules found in a .htaccess file in the same folder. The PHP script just outputs whatever data was passed to it in the query string along with the GET request.

In other words, there is an .htaccess file which is allowing a variety of fancy URLs to all internally point to the same PHP script. Each URL is meant to exhibit a slightly different aspect of URL rewriting that may be useful to you. Several of them focus on passing data through the query string even though there is no query string in the fancy URL.

You will definitely want to read that tutorial linked above before going in to read the code in this example.

The direct URL to the example script is http://onepotcooking.com/amosbloomberg/spring2010/class10/mod_rewrite/index.php

The fancy URLs that internally rewrite to that same script are:

• http://onepotcooking.com/amosbloomberg/spring2010/class10/mod_rewrite/a-slick-server-side-rewrite
• http://onepotcooking.com/amosbloomberg/spring2010/class10/mod_rewrite/a-slick-server-side-rewrite-with-query-string
• http://onepotcooking.com/amosbloomberg/spring2010/class10/mod_rewrite/2009/05/05/archive.html
• http://onepotcooking.com/amosbloomberg/spring2010/class10/mod_rewrite/2009_05_05_archive.html
• http://onepotcooking.com/amosbloomberg/spring2010/class10/mod_rewrite/article/10

And the following URL uses mod_rewrite to do a client-side redirect (not a rewrite):

• http://onepotcooking.com/amosbloomberg/spring2010/class10/mod_rewrite/an-easy-client-side-redirect

Reminder: all the rules that allow these URLs to point to and pass data to the same index.php script are found in the .htaccess file in the same folder as the PHP script.

In an effort to provide a last bit of constructive criticism, here are some comments on each of the final projects:

Alma F – http://onepotcooking.com/almafuentes/class10/

• I would center the content of the page unless there’s a reason not to.  Use the margin: 0 auto; technique in the CSS for the container div.
• nice logo – I would make it link that takes you to the “home page”.  You’ll see that most sites make the logo a link – just wrap the <img> in an <a> tag
• the bottom of the content of the page is flush with the bottom of the browser.  I tend to put a bit of margin on the bottom of the container <div>…
• the blue border around the image on the home page makes it look a bit old-school.  I would remove it, but make sure to put instructions such as “Click a brain part…” at the top of the page so people know that there are links in the image.
• nice job with the tabs, breadcrumbs, and all.

Andras H – http://onepotcooking.com/andrashamza/finalproject/

• don’t be afraid to put some padding in your divs so the text is not flush against the border
• design-wise, I would remove the borders around almost all of the divs
• and maybe put in a few photos in the “about me/contact” sections to lighten it up a bit and make it less text-heavy
• be a bit less modest in your footer – this is all your code.
• on the drag-and-drop example, I would pop up some sort of modal dialog from the JQuery UI when a user drops the draggable in the droppable
• in the lightbox example, I would use thumbnail images that are all the same size to make the design look smoother… and remove the blue border around the images or replace it with a different color border.  As with Alma’s site, blue borders make it look like old-school HTML.
• with a little design help, this could be a great portfolio

David T – http://onepotcooking.com/davidthomas/finalproject/

• nice JQuery effects when the page loads
• the logo and images with faded backgrounds make the site look a bit dated.  check out some “Web 2.0″ photoshop tutorials for more modern-looking design effects.
• i assume the borders around all the divs are just for testing…
• it looks like you are setting a “height” property for the container div – this is generally a bad idea.  Try to remove the height on the container so that the height of the container exactly matches the height of the content inside of it.  If this causes your page to display strangely, then there are other problems in the code that are preventing it from displaying correctly.

Doug S – http://onepotcooking.com/dougsmith/final_project_php/

• very nice, clean, obvious information architecture of the home page
• i would not link directly to the sites listed in the left nav – I would first link to a short description page on your own site that then has the links to the actual external site… like what you’re already doing on the “Top 5″ page – it makes a smoother well-curated experience
• some of the images in your cycle slideshow look stretched.  use photoshop to resize all images to the same size to prevent this.
• the ad in the top nav area and the zipcar ad are not actual links – wrap them in <a> tags to make it a link to their respective sites
• great straightforward site, although I’m still confused about the airtrain, but that’s not your fault

Luca T – http://onepotcooking.com/gianlucatixon/assignment/my_project/

• the title of the page still says, “Class 2 – CSS Layout”
• the translation links and Google maps feature are nice reminders that there are a lot of cool features that our sites can offer which do not require you to write code from scratch
• the idea of the site is great, but the details need to be filled in
• the XHTML code could be cleaned up, but it’s a good start

Heidi F – http://onepotcooking.com/heidifaucette/project/

• the deceptive simplicity of the design really lets the art speak for itself
• i like how the gallery photos are skewed to make them seem less technical
• the top nav links jump around a bit when you mouse over them.  This is because they are currently “inline” elements whose width varies depending on the width of the text inside of them.  If you put each link inside a “block” element, such as a “div”, with a fixed width, this won’t happen.  You can also convert <a> tags to be block elements with a fixed width in the CSS: a.top_nav { display: block; width: 150px; }… and remember that you’re then going to have to float them if they’re block elements so that they line up side-by-side.
• on the slideshow page, I would remove the blue borders around the image thumbnails.. maybe replace it with a light gray border instead
• I would include a copyright notice on the bottom of all pages.  Note to all: to put the copyright symbol on the page, use the &copy; html entity.
• very nice site – hope she’s happy

Jenna R & Samantha W – http://onepotcooking.com/samanthawildenstein/finalproject/

• nice site name – is that inspired by onepotcooking?
• the simple design and gradients add a lot to the look of the site
• nice use of the cycle slideshow – I would make it even bigger and more prominent on the home page
• the width of the logo section does not exactly match the width of the main navigation section…  i would make them exactly the same width
• the layout of the pages is simple and clean, and makes it easy for you to add more content later
• I would put a fake ad in the ad space just to show what it would look like… you can check out this site for info about standard ad sizes and for placeholder images.

Jeremy M – http://onepotcooking.com/jeremymorgan/final_project/

• very nice cleanly designed
• great image at the top – is that your design?
• the information architecture nicely removes attention from the fact that there is not much example work here – the average viewer would ever even think about that
• the top element of the accordian seems to change between an image and a list item depending on whether its exanded or not… i wonder if there’s some way to make it obvious that this is where the image is even when its collapsed…
• great use of a few simple effective tools – sites don’t have to look complicated

Jim R – http://onepotcooking.com/jimristovski/finalproject/

• the photo of John Mendez looks squashed… be sure to resize all images in Photoshop to the sizes you want to use on the web.
• very nice, clear information architecture
• the yellow somehow is not disturbing, although I would remove some of the borders around the main top, left, right, and bottom navigation sections to keep the layout looking a bit more cohesive
• in the “featured listings” section, I would make the title of the listing a link to the detailed info on that listing
• maybe give a bit more padding to each listing section so the image is further away from the border
• i would also use a different font color for listing price and listing title to separate them visually
• on the listing detail page, I would replace the blue border around the images with a different color
• I’d put an image in the “credentials” page to make it less text-heavy
• all-in-all a great example of a simple-to-use, well-architected, database-driven site

Katherine A – http://onepotcooking.com/katherinearathoon/finalproject/

• very useful idea
• great favicon
• it would be great if you could click on any correct answer to get a JQuery UI modal dialog with more information about that answer
• the numbers of the questions are totally out of order – is this on purpose?  If not, you can order them using the ORDER clause in the SELECT query, as outlined in this post.
• another great example of an easy-to-use database driven site.  such a simple useful idea and nice execution.

Mark P – http://onepotcooking.com/markpetimezas/final_project/

• there’s a blue border around the first image that loads up in the home page slideshow – I would remove this and find some other way to indicate that the image is a link
• really great use of the cycle slideshow
• i really like the layout and design of all the pages, and the logo
• the lightbox slideshow has blue borders around the images – I would override the borders for all image to prevent image links from having borders in the CSS: image { border: 0; }
• i’m assuming the contact page will eventually have the same style as the other pages
• i would make the logo a link to the home page
• great site, hope the client is happy

Paddy S – http://onepotcooking.com/paddysullivan/finalproject/

• i would make the top nav links all evenly spaced – that’s more difficult than it sounds.
• maybe make the lyrics or the inspiration visible by default so there’s something to read when the page first loads
• also, I would use text links for the show/hide functionality rather than buttons to make it look a bit more discrete.
• also, try to align the comment form fields so they look neater
• looking forward to posting songs

As we discussed in class, registering a website domain (e.g. registering a name such as “onepotcooking.com”) is a different transaction from hosting a website (i.e. renting space on a server where you can put your files).

However, most web hosting companies also throw in a single domain registration as a freebie for signing up for one of their web hosting plans.  Plus, I have a promo code here that you can use to get further discounts from Dreamhost.

The Dreamhost promo code I am posting here will get you $20 off of a pre-paid monthly plan, and $40 off of a pre-paid yearly plan.  I get a nice bonus by referring you, so although I think this is a pretty great discount for you, I also benefit by promoting it.  It’s a good deal all around, but obviously you should still compare prices with others like StartLogic, GoDaddy, etc.  There is no lack of competition in this market.

The Dreamhost promo code is:

WEBDEVSUMMER09

Probably the best selling point is that your own setup will be almost identical to what we used in class, since onepotcooking.com is hosted on the cheapest basic Dreamhost shared hosting plan.

I find it to be no-nonsense, well set up, relatively open, and with a very straightforward control panel that allows you to easily create and manage databases, email addresses, one-click installation of many pieces of common software such as WordPress and others, and few restrictions on usage.  But it does have its ups and downs like any other hosting provider. I am not personally as familiar with the equivalent plans at other hosting companies, but I assume they all offer the same basic functionality.

Here are the links to the final projects completed in the summer course.  Please send me any additions and/or corrections.

• Alma F – http://onepotcooking.com/almafuentes/class10/
• Andras H – http://onepotcooking.com/andrashamza/finalproject/
• David T – http://onepotcooking.com/davidthomas/finalproject/
• Doug S – http://onepotcooking.com/dougsmith/final_project_php/
• Luca T – http://onepotcooking.com/gianlucatixon/assignment/my_project/
• Heidi F – http://onepotcooking.com/heidifaucette/project/
• Jenna R & Samantha W – http://onepotcooking.com/samanthawildenstein/finalproject/
• Jeremy M – http://onepotcooking.com/jeremymorgan/final_project/
• Jim R – http://onepotcooking.com/jimristovski/finalproject/
• Katherine A – http://onepotcooking.com/katherinearathoon/finalproject/
• Mark P – http://onepotcooking.com/markpetimezas/final_project/
• Paddy S – http://onepotcooking.com/paddysullivan/finalproject/

We have talked a bit about SEO and optimizing your site to be indexed by the major search engines in searches for particular keywords.  We generally, but not always, want to make it easy for search engines to figure out what any given page is about.  So it only seems appropriate that we should discuss the opposite procedure: how to prevent search engines from indexing your site.

The major search engines, run by Google, Yahoo, and Microsoft, send out spiders, which are automated programs that crawl the web in search of websites.  Every page on every website a spider encounters is analyzed, categorized, and logged in a giant database.  That database is what is used when someone does a search on a search engine for a particular term.  If your site has been categorized as being related to that term, your site will show up in the search results on the search engine’s website.

Before any of the major search engines’ spiders index the contents of your site, they will look for a file on your web server called robots.txt.  If you want to prevent the search engines from indexing your site and mentioning it in their search results, you should create a robots.txt file and upload it to the root folder of your website.

To prevent spiders from indexing the entire site, put this code into your robots.txt file:

User-agent: *
Disallow: /

To prevent spiders from indexing only the subdirectory called “private”, put the following code in your robots.txt file:

User-agent: *
Disallow: /private/

To prevent spiders from indexing both the “private” folder, and another folder called “my_stuff”, use a robots.txt file with the following code:

User-agent: *
Disallow: /private/
Disallow: /my_stuff/

And so on.  You can repeat the “Disallow” command with as many folders as you want to keep private.

For more information about robots.txt,check out The Web Robots Pages.

You should consider the URL address of your site to be part of its design.  A memorable URL, and a nicely designed favicon are probably the first two things anyone sees of your work.

Intro to Favicons, Fancy URLs, and Search Engine Optimization

To read about what a favicon is, and how to create one, click that link.

To read about what I mean by fancy URLs, and how to create them, click that link.  A simpler example than those found on this link follows in this post.

Fancy URLs, meaning intuitive URLs that are easy to understand, are also important for Search Engine Optimization (SEO).  Click to read more about developing your web site with SEO in mind.

An example of Fancy URLs

I will now outline a relatively simple example of creating Fancy URLs.  Click to see  this example in action.

By clicking that link to see this example in action, your browser will bring you to this URL:

http://onepotcooking.com/amosbloomberg/summer2009/class9/mod_rewrite/animals/

If you click one of the animal names in that file, your browser will bring you to a URL that looks like something like this:

http://onepotcooking.com/amosbloomberg/summer2009/class9/mod_rewrite/animals/15

The first thing to notice is that if you view the files in that project folder on the server, you’ll see that there is no subfolder called “animals/ ” in there.  So Fancy URLs are a euphemism for Fake URLs.

The .htaccess file

The file named .htaccess in this folder contains a few rules that make this trick possible.  The first rewrite rule in the file is this:

RewriteRule ^animals/$ index.php [QSA]

This says that if the browser requests the folder “animals/“,  the server should respond by sending the file “index.php” to the browser instead.

The second rule looks like this:

RewriteRule ^animals/([0-9]+)$ index.php?animal_id=$1 [QSA]

This rule says that if the browser requests the folder “animals/” followed by any number, such as “animals/15“, then the server should convert that into a request for the file “index.php?animal_id=15″ instead.

As you can see, in this second rule, part of the Fancy URL has been converted into a bit of data passed via the query string along with the request for the file.  This is a common trick to make it less obvious that data is being passed to the server with the request.

The fundamental concepts of e-commerce are easy enough to grasp, and these days most e-commerce sites follow normative standards and conventions. There are three basic components: the storefront, the shopping cart, and the checkout.

In this post, I’ll discuss each of these components.  How these components are implemented in code depends, like many advanced topics, on what framework you’re working with, what language, and the style of development you or your team have.

The Storefront

When someone is shopping on the web, they want to browse products on a site to see what’s available. Usually, products use categorization to make it easy for users to find the sort of products they’re looking for.   If you remember from way back when, we discussed the elements of navigation that an information architect should be aware of.  It might be good to review those now that you’re finalizing plans for your final projects.

A shoe store typically has top-level categories such as Men’s and Women’s. A shoe store might also have one or more levels of sub-categories of each top-level category. For example, the Men’s category might have sub-categories such as Boots, Sandals, Dress Shoes, Sneakers etc.

It is not uncommon for a particular product to fall into more than one category. For example, a casual hiking boot may fall under both Hiking and Casual.

Now for a small tangent on the topic of categorization: A modern twist on the idea of categorization is tagging, mentioned in that earlier blog post about navigation. Many sites, especially “Web 2.0” sites, now offer tags in addition to, or as a replacement for, categories. Tags are just keywords that are associated with a particular product. Often, but not always, tags are user-generated, meaning that users of a site can add whatever keyword they want to a particular product. If users can collaboratively add tags to a product or asset, then the site offers what is known as a folksonomy.

Managing the storefront of an e-commerce site is a matter of organizing products, and managing inventory. How you organize the storefront, and how you categorize your products, are important concepts to work out in the information architecture phase of an e-commerce project, since the methods of navigation and categorization that you choose will affect every aspect of the site architecture.

In terms of development, a storefront would have separate database tables for categories, products, and the association of products to categories.  All the data about categories and products would then be read from the database.  Storefronts must also begin a “session“, which automatically assigns a session id to the user and stores it in a cookie.  This is important so that the server can track each user and make sure that one user’s shopping cart is not confused with another user’s shopping cart, even if the user’s are not registered with the site.

A typical categories table might have fields for id, title, parent_category_id, and created. A products table would typically have fields for id, title, description, num_available, price, thumbnail_image_path, large_image_path, and created. An association table could have fields for id, product_id, category_id, created, thereby allowing for a many to many relationship between products and categories by thereby having a separate row for each category a particular product belongs to.

The Shopping Cart

Shopping carts are an essential part of any e-commerce site. They take the metaphor of the physical shopping basket, and transpose it into online media. At its most fundamental, a shopping cart is tool for maintaining state and remembering which products a user has selected for purchase so that they can buy them all together as a batch without having to re-enter their billing and shipping info for each one individually.

As you can probably imagine, most shopping carts are simply tables in a database that have fields for user_id, product_id, and quantity (as well as the id and created fields, of course). That way, the database table simply has a row for every product in the user’s cart. To get the contents of the cart, you make a query on the table for all rows that match a given user_id.

It may be that you want to allow non-registered users to also add items to a shopping cart.  In this case, you wouldn’t be able to store their user_id in a database since they do not have a user_id.  There are two ways to get around this problem: either you store the items in their cart as data in a cookie (stored on their client machines) instead of in the database, or you can add a temporary shopping cart table to the database that associates items with a user’s session_id rather than their user_id.  Remember that session_ids are automatically assigned by PHP’s Sessions functionality, and do not require users to register.  The temporary shopping cart table might be called, “temp_cart”.  It might have fields for id, session_id, product_id, quantity, and created.

Payment Processing

The checkout and payment processing parts of an e-commerce site are the most complicated. You need to securely process a transaction on a user’s credit card. This entire process should take place on a secure server where all communication between the client and server is encrypted.

In order to process credit cards online, you need to have what is known as a merchant account with a bank. To charge cards over the phone, in a store, or online, merchants need these special accounts with a bank.  If you do not have a merchant account with a bank, you will need to use a payment processing service like PayPal, which does not require you to have your own merchant account setup.  PayPal uses its own merchant account to process your payment (and of course they charge an extra fee for this.)  This is why PayPal is so popular with small merchants.

Assuming you have a merchant account (or are using a payment service that does), the first step in processing payment online is to send the data of what items are in a user’s shopping cart to a script that then calculates the total fee owed, as well as an taxes and surcharges. Once the user enters his/her credit card, billing, and shipping info, you perform a transaction on their credit card by first authorizing it with the issuing credit card company.

If the credit card authorization passes, you must process the order with the credit card company by charging their card, remove the items from the user’s shopping cart, and make sure your site’s product inventory (the num_available field in the products table) is up-to-date now that you have sold off a few items. Once everything is finished, you show a confirmation screen to the user with an order receipt. Often, the site will automatically send an email to the user (assuming they entered an email address) with the order receipt in it.

One rule of thumb to follow if you are running your own store is never store sensitive information like credit card numbers in your database. Unless you have a budget to hire a good security expert, your site can be (and very well may be) hacked, and you do not want to be liable for the damages that would result from someone getting a hold on your clients’ credit card numbers.

Due to the complication of doing all these steps yourself, most online merchants opt to use a third-party payment processing service that provides security and handles all the dirty work of charging a card for them. I recommend you do the same.

Conclusion

The components of an e-commerce site are really just a new combination of the techniques and technologies you are already familiar with.  However, given the amount of work it takes to get all the interaction between the parts working correctly, it can be very time consuming to set up.  Also, given how important it is that you do not make mistakes or errors in any of the steps, the risk associated with developing a homemade shopping cart is pretty high.

For these reasons, I recommend you use a 3rd party library or content management system (CMS) to do as much of this work for you as possible.  A popular 3rd party library or CMS should be well-tested, secure, easy for you to integrate with your site, and easy for the user to navigate. So when you are evaluating 3rd party tools, bear each of these issues in mind.  Also determine whether the software handles all of the storefront, shopping cart, and payment processing, or only some of those parts.

As an example of a popular e-commerce CMS is Zen Cart.  There are a variety of e-commerce “solutions”, including:

• PayPal Shopping Cart (handles just the shopping cart component).  See also this code example of integrating a simple web site with PayPal Shopping Cart.
• PayPal Payment Processing (handles just the payment processing part)
• Google Checkout (Google’s attempt to nudge into PayPal’s market domination)
• Authorize.net Payment Processing (handles just the payment processing part – requires you have a merchant account with a bank)
• X-Cart (open source.  handles the storefront and shopping cart; is built to integrate with the popular payment processing services)
• Zen Cart (handles the storefront and shopping cart; is built to integrate with the popular payment processing services)
• Magento (handles storefront, shopping cart, and payment processing integration)
• WordPress e-Commerce (a WordPress plugin that adds storefront, shopping cart, and integration with payment processing services)

These are just the one’s I have heard of recently.  You will find that there are dozens of PHP-based e-commerce solutions available with just a simple search.