Web Dev 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 members
• 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 member

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/LINUX 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/examples/class10/mod_rewrite/index.php

The fancy URLs that internally rewrite to that same script are listed on that page.

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.

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 store-front, 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 Store-front

When someone is shopping on the web, they want to browse products on a site to see what’s available. The listing of how products are displayed on your site is termed the “store-front”.

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 when organizing the content of a site.

In terms of information architecture…

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.  You may also want to add the ability for visitors of your hypothetical shoe store to search products by facets, including price, color, brand,  specials, etc.

Managing the store-front of an e-commerce site is a matter of organizing products, and managing inventory. How you organize the store-front, 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 store-front, if you were to build one yourself, would most likely 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.  Store-fronts 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.

In terms of development…

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.

To have a merchant account or not to have a merchant account?

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 or Google Checkout, 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. So the first step is a transfer of information from the shopping cart to the payment processing service.  Once the user enters his/her credit card, billing, and shipping info in the payment processing step, 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, such as Authorize.net or PayPal, 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 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 store-front, shopping cart, and payment processing, or only some of those parts.

There are a variety of e-commerce “solutions” that handle some or all of the components of e-commerce mentioned above.

Simple e-commerce shopping cart solutions include:

• PayPal Shopping Cart – handles just the shopping cart component, and links with PayPal’s payment processing site to handle payment processing.  You would have to build your own store-front with this solution.  See also this code example of integrating a simple web site with PayPal Shopping Cart.
• Google Checkout – Google’s attempt to nudge into PayPal’s market domination.  You would have to build your own store-front with this solution.

Popular solutions for both the store-front and shopping cart include the following content management systems:

• LemonStand – an e-commerce CMS.  This is a commercial product.
• X-Cart – an open-source, free e-commerce CMS.  Handles the store-front and shopping cart; is built to integrate with the popular payment processing services, such as PayPal or Authorize.net.
• Zen Cart -an open-source, free e-commerce CMS.  Handles the store-front and shopping cart; is built to integrate with the popular payment processing services, such as PayPal or Authorize.net.
• Magento – an e-commerce CMS.  Handles the store-front and shopping cart; is built to integrate with the popular payment processing services, such as PayPal or Authorize.net.

Popular payment processing solutions include:

• PayPal Payment Processing – handles just the payment processing part.  Does not require you to have a merchant account with a bank.  Assumes you already have a store-front and shopping cart in place.
• Authorize.net Payment Processing – handles just the payment processing part.  Requires you have a merchant account with a bank.  Assumes you already have a store-front and shopping cart in place.

In addition to these stand-alone solutions, there are a variety of WordPress plug-ins that add store-front and shopping-cart functionality to a WordPress site.  Some popular ones include:

• WordPress e-Commerce – a WordPress plugin that adds store-front, shopping cart, and integration with payment processing services
• Shopp - a WordPress plugin that adds store-front, 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.

In class today, we’re looking at an example of how you can use the SimplePie PHP library to pull content from any site’s RSS feed and display it on your own pages.

In this example, SimplePie is acting as the Model in an MVC architecture. index.php is the Controller, and index_view.php is the View.

In the example files, you will notice that there is a folder called “cache”. This is where SimplePie temporarily stores copies of the RSS feeds that you load. It keeps each cached copy of the RSS feed for several minutes, so that if you reload your page, it doesn’t have to always reload the same data from the site that publishes the RSS feed.

In fact, some sites will ban your site from accessing their RSS feeds forever unless you store cached copies of their feeds. This is because they want to minimize the number of requests that are made to their servers. SimplePie does this by default if you have a “cache” folder available.

You’ll also notice an “images” folder.  This stores default placeholder images for media files.  SimplePie integrates with the JW Media Player application.  So if a particular RSS feed has media attachments, whether audio or video, SimplePie will automatically generate the appropriate JW Media Player code, so you don’t have to worry about doing it yourself.

If you use SimplePie, you will need to make sure you have the simplepie.inc file (which holds the main SimplePie code), the cache folder (which stores cached copies of all RSS feeds), the images folder with default images, and the idn folder (which holds other misc SimplePie files).

To play audio or video files on a web page consistently across all the browsers, you will want to use a Flash media player. Adobe Flash is the most widely supported application on the web for playing audio and video files.   As we mentioned early in the course, Flash is also commonly used to do animation on the web.

There are a variety of Flash media players available online, some free, some not.  One of the most common, and easiest to use, is the freely available JW FLV Media Player.  The nice thing about the JW FLV Media Player, and other players of its ilk, is that you can relatively easily skin it to make it fit the design of your site.

The bare bones approach

Note: While the following is the simplest way to put a Flash application on your page, and it is worth understanding, it is not the recommended approach.  Skip below for the recommended approach.

To place any Flash application on your web page using simple XHTML, you will need to use either the <object> tag, or the <embed> tags in XHTML.  Historically, the <object> tag was used for Internet Explorer, and the embed tag was used for the other browsers.  However, these days, <embed> is not considered to be valid XHTML, and it is no longer recommended for use.  However, most modern browsers continue to support it.

The FLV Media Player apploication we will be using to play media files can be put on a page using the following embed code:

<embed
	src="mediaplayer.swf"
	pluginspage="http://www.macromedia.com/go/getflashplayer"
	type="application/x-shockwave-flash"
	quality="high"
	wmode="transparent"
	flashvars="file=http%3A%2F%2Fwww.mos.org%2Fmedia%2Faudio%2F081121MOS_CSTPodcastTMGrapheneDDEelsX.mp3%3Ffile_extension%3D.mp3&amp;autostart=false&amp;repeat=false&amp;showdigits=true&amp;showfsbutton=false"
	width="100%"
	height="20"
/>

The “src” attribute tells the embed tag where to locate the flash media player file.  Obviously, you need to make sure you have a copy of mediaplayer.swf in your own directories in order for this to work.

We then pass a parameter to this media player that indicates which media file it should play.  The path to this media file goes inside the “flashvars” attribute.  Notice that in this example, in the “flashvars” attribute, we are telling the media player to load a media file from another server.  We could just as easily load a media file on our own server using a relative path instead of an absolute path.  Also notice that the path to the media file is urlencoded.

To see this example in action on our server, click here.

The recommended approach

This example is the same as the first example above, but it uses the Javascript SWFObject.js library to put the Flash player on the page instead of using the <embed> tag.  The SWFObject.js library is just a bit of code that creates the embed tag in Javascript and then places it on the page without you having to write it in XHTML.  You’re probably wondering why you would want to use it…

This page gives a good overview of the two methods, the problems with the XHTML version, and the reasons for using the Javascript version rather than the XHTML version.

The code requires that you have downloaded the swfobject.js script, and have put it in a subfolder called “scripts” on your server.  Once you have the file uploaded, you can included it into your XHTML file in the head of the document:

<head>
  ...the usual stuff in the head
  <script type="text/javascript" src="scripts/swfobject.js"></script>
</head>

Once that’s taken care of, you put the JW FLV Media Player onto your page using this example code:

<script type="text/javascript">
  var so = new SWFObject('mediaplayer.swf','mpl','100%','20','9');
  so.addParam('flashvars','file=http%3A%2F%2Fwww.mos.org%2Fmedia%2Faudio%2F081121MOS_CSTPodcastTMGrapheneDDEelsX.mp3&autostart=true');
  so.write('flashplayer');
</script>

Notice that the parameters are basically the same as we saw in the <embed> example: the location of the Flash application file, the width and height of the application, and the location of the media file that we want the media player to play.  The difference, of course, is that these parameters are specified in Javascript.

PS: In case you didn’t notice, these parameters are obviously arguments being sent to the constructor function of an object in  Javascript, similar to how we used constructor functions in object-oriented PHP.