February 20th, 2010 § 0
Your assignment is to convert this wireframe diagram into valid XHTML code:
wireframe for class 2 in-class assignment
As always, start with the bare minimum elements necessary to make an XHTML page, and move forward based on the XHTML common elements example code.
Hint: you will want to use the align attribute of the <img> tag in order to have the image sit next to the paragraph of text. You should look up the <img> tag reference page on the w3schools.com site for more information.
December 5th, 2009 § 0
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.
There will be four pages that the user sees:
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:
The Controller scripts that I have created for this application to handle these tasks are:
As should be clear by now, Models are necessary to handle the parts of this site where direct access to the database is needed:
The Model scripts that do these tasks are:
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.
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.
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.
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.
December 5th, 2009 § 0
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>
November 6th, 2009 § 0
Understanding how to use the $_GET, $_POST, and $_REQUEST variables is critical to creating a site in PHP. So here is an in-depth analysis of how data is passed from one page to another using forms.
In our earlier post, we discussed the concept of persistent data. Each web page is like a distinct application that does not share any information with any other web page. But sometimes, you want one script to communicate with another script. Sometimes two different pages need to share data.
In this post, we’re going to take a look at three things:
As an example, let’s say we have created a website where users can sign up to receive a free guide to Sri Lankan real estate in the mail. So there is a form that the user has to fill out where they enter their shipping address. When the user clicks the “submit” button on that form, that data that they entered is taken from the page on which they entered it, and is sent to another script using either a GET or POST request to the server.
These two types of HTTP requests, GET and POST, are the primary ways that a browser can make requests pages from a server. (For an overview of all possible types of requests and responses between web clients and servers, you can look up the HTTP reference page on Wikipedia).
Let’s imagine that index.php is the XHTML code for the form where the user enters his shipping information. This form just has a bunch of text fields that a user fills in with his shipping address. Then the user clicks “Send it now!” to submit the form:
<form action="process_signup.php" method="POST"> <label for="full_name">Name:</label> <input type="text" id="full_name" name="full_name" /> <br /> <label for="street">Street:</label> <input type="text" id="street" name="street" /> <br /> <label for="city">City:</label> <input type="text" id="city" name="city" /> <br /> <label for="state">State:</label> <input type="text" id="state" name="state" /> <br /> <label for="zip">Zip:</label> <input type="text" id="zip" name="zip" /> <br /> <input type="submit" value="Send it now!" /> </form>
When viewed in the browser, and surrounded by the usual <html>, <head>, and <body> tags, this page, without any style sheets, will look something like this:
A simple form
When the form is “submitted”, what this means in technical terms is that the browser actually makes an HTTP POST request to the server for the file, process_payment.php. We can tell this because the <form> tag has two attributes: “action” and “method”, which indicate what the browser should do when the user clicks the submit button.
<form action="process_payment.php" method="POST">
The “action” attribute indicates which page the browser should request when the user clicks submit. The “method” attribute indicates which HTTP type of request the browser should make. In this case it’s a POST request.
The POST request asks the server for the process_signup.php file, but along with that request it also sends the data the user entered in the form to the server. That data is sent in a way that is invisible to the user, hidden in the HTTP headers that the browser uses to make the formal request the server for the process_payment.php file.
If we were to somehow intercept those invisible headers that the browser sends as its formal request to the server, they would look something like this:
POST /process_signup.php HTTP/1.1 Host: www.mysite.com User-Agent: Mozilla/4.0 Content-Length: 27 Content-Type: application/x-www-form-urlencoded full_name=Amos+Bloomberg&street=145+4th+Avenue&city=New+York&state=NY&zip=10003
The top part are the generic HTTP POST headers indicating what file the browser wants, and what kind of client the browser is. The bottom line contains the urlencoded data that the user entered in the form. This is how POST method submits data to the server. But you’ll never see any of that since it is never shown to the user.
Notice that the data in the bottom line holds the data that the user entered as a series of key=value pairs, with a very specific syntax:
key1=value1&key2=value2&key3=value3 ... and so on...
In urlencoding, all key/value pairs are separated by ampersands, “&”. The key to each piece of data from a form is always the “name” attribute of the XHTML form field in which the user entered the data. The value is always the text that the user entered.
So “full_name” is what we put in the “name” attribute of the first <input> tag in the form…
<input type="text" id="full_name" name="full_name" />
..so that’s the term that is used as the key to that piece of data in the HTTP POST request that is sent to the server.
full_name=Amos+Bloomberg&street=145+4th+Avenue&city=New+York&state=NY&zip=10003
“street” is what we used as the “name” attribute of the second <input> tag in the XHTML, so that’s what is used as the key to the second piece of data in the HTTP POST request. And so on for all the other form fields.
Once that form has been submitted and the HTTP POST request has been made to the server, the server sees that the file that the browser requested is a PHP script, so it runs that script on the server before sending anything back to the client.
PHP, since it is built specifically for the web, is smart enough to know that the PHP code in the scripts on the server might be interested in the details of the data that was sent along with the HTTP request, meaning the data that the user entered in the form. So PHP provides a few special variables that contain that data in an easy-to-use format.
The $_POST variable is built-in associative array that automatically is set to hold all of the data that was sent along with in any HTTP POST request to the server. The index of each element in the associative array is the same word that was used as the key in the key=value pair that represented that data in the HTTP request. This is also, if you recall, always the same word as the “name” attribute of the form field in which the user entered the data.
So in our example, the $_POST array will have 5 elements. If we were to dump out the raw data stored in the $_POST array in our PHP script using the built-in print_r() function, which we always use to debug arrays, it would look something like this:
Array( full_name => Amos Bloomberg, street => 145 4th Avenue, city => New York, state => NY, zip => 10003 )
We can access each element in the array individually in PHP by using the $_POST array with the correct term as the index, using the syntax $_POST['<index name>']. For example:
$fullName = $_POST['full_name']; $street = $_POST['street']; $city = $_POST['city']; $state = $_POST['state']; $zip = $_POST['zip'];
The important thing is that the index that we use each time we access the $_POST array is the same word that we used in the “name” attribute of the form field <input> tag in the XHTML page where the user entered their address.
Assuming all the names we use as indexes for the $_POST array in the PHP match the “name” attributes of all the form fields the user filled in on the XHTML page, we will have successfully passed data from one page to another. Data the user entered from the form has been passed to the PHP script.
Assuming the XHTML “names” and the PHP indexes match, we will now have the data that the user entered in the form stored in our variables, $fullName, $street, $city, $state, and $zip. And we can do whatever we want with that information, for example storing it in a database, or sending it in an email to someone.
As an alternative, we could have used the HTTP GET method instead of the POST method when submitting the form. To do this, we would have changed the form tag in the XHTML to be:
<form action="process_payment.php" method="GET">
The practical difference between the two is that with GET, the data that the user enters in the form is attached to the URL of the file that the client is requesting from the server. And users will see the data they entered in the form show up in the address bar of the browser, when it requests the file process_signup.php, so data passed along with a GET request is not invisible or hidden from the user.
Browser address bar with HTTP GET request data
If we were to intercept the headers in an HTTP GET request to the server, it would look something like this:
GET /process_signup.php?full_name=Amos+Bloomberg&street=145+4th+Avenue&city=New+York&state=NY&zip=10003 Host: www.mysite.com User-Agent: Mozilla/4.0
Notice how the data the user entered in the form is tacked on to the end of the file name that the browser is requesting from the server. The user will see all this data in the browser address bar as well.
Just as the data sent along with the POST request to the server in our original example was automatically stored in a $_POST variable in the PHP script on the server, process_signup.php, the data sent along with the GET request is automatically stored in a $_GET variable. And you can access that data in almost the exact same way you did with the $_POST variable in your PHP code:
$fullName = $_GET['full_name']; $street = $_GET['street']; $city = $_GET['city']; $state = $_GET['state']; $zip = $_GET['zip'];
So, as I hope is obvious, the $_GET variable only holds data that was passed to a PHP script via the GET method. And the $_POST variable holds only that data that was passed to the server via a POST request. Do not try to mix and mingle the two.
Whereas the $_GET variable only holds data passed to the server with an HTTP GET request, and the $_POST variable only holds data passed to the server in an HTTP POST request, the $_REQUEST variable holds any data passed to the server along with either type of request. It also holds data passed via cookies.
The $_REQUEST variable is a sort-of catch-all for any data passed to the server, regardless of how it got there. So regardless of whether the form used the method POST or the method GET, we could use this code in the PHP script to access the data:
$fullName = $_REQUEST['full_name']; $street = $_REQUEST['street']; $city = $_REQUEST['city']; $state = $_REQUEST['state']; $zip = $_REQUEST['zip'];
As you can see, the built-in $_REQUEST variable is an associative array with indexes that are the same words we used in the “name” attribute of each field in the XHTML form, just as $_POST and $_GET were.
October 24th, 2009 § 0
This week marks the end of covering the client-side technologies, XHTML, CSS, and Javascript. Next week, we will begin with the server-side technologies, PHP, and MySQL. So the major assignment for this week is to make sure all your assignments from past weeks are completed, working, and linked from your blog so I can grade them. There will be a general amnesty for late assignments – if you complete them by the end of the week, you will receive a full grade.
PS: Please test the links to your assignments before posting them to your blog. If the links don’t work, then I can’t see your assignments, which means you get a zero grade for them. Not a happy conclusion to your hard work. Also, a screenshot of your assignment is not a substitute for a link to it. There are several of you who are repeat offenders on both counts – please go through your old posts and make sure all links to past assignments are present and working.
The assignments so far are:
We will be having a quiz next week on the client-side material, so please make sure you have done all the assignments and gone through all the previous reading material that has been assigned.
October 10th, 2009 § 0
For those of you who have completed assignment #1, your next assignment is to go through the same process with this new design comp:
The image files necessary for this assignment are, as with the previous one, available on the server here.
The global navigation buttons (i.e. “Home”, “Friends’ Videos”, “Featured Videos”) should be done using an unordered list <ul> element, as recommended in the previous assignment.
The only font used on this page is Tahoma.
Some of the background colors used are #F7F7F7 and #D8DFEA.
The light gray borders used between listings in the “Recent Activity” area is #DDDDDD.
The “+” and heart buttons that show up to the right of each video in the “Recent Activity” section should use the sprite rollover technique we discussed in Class 3. The example of the sprite technique is available here.
October 10th, 2009 § 1
The first assignment for this week is to convert the following design comp into valid XHTML and CSS code. All the necessary images have been pre-cut by your thoroughly competent in-house graphic designer, and are available in the images sub-folder on the server.
The fonts used on the page are Georgia for the serif font, and Arial for the sans-serif font.
To begin converting any design comp into XHTML and CSS code, I would recommend setting up a basic page with the design comp applied as a background image to the container div, following the background image technique outlined elsewhere.
Then, start thinking about how you would create an outline structure with the proper rows and columns. This usually means thinking in terms of the container div and second-level divs that you can create to generate the basic sections of the page without worrying about the content that goes into each section yet.
If the design comp shows columns of content that sit side-by-side, you may want to look into using the clear/float layout technique, if necessary, which is how you coerce block elements, such as divs, to sit side-by-side.
Avoid using the CSS position or z-index properties. It is usually not necessary, and is often a source of trouble for inexperienced developers. Usually, you can position elements properly through a combination of margin and padding, and the float and clear trick.
For this comp, I would start with an outline of the page in the <body> of an XHTML document, something like the following:
<div id="container">
<div id="main_navigation">
</div>
<div id="search_bar">
</div>
<div id="search_results">
</div>
<div id="footer">
</div>
</div>
This simple XHTML code has all the major sections of the page broken up into divs. Now your job is to use CSS to put them into their appropriate positions and sizes.
Once you have the basic layout of the sections done, you can move on to more specifics, and start to think about how some of the parts of the content would be coded in the XHTML.
The global navigation looks like this:
This is not so different from the global navigation menu example we looked at in class, where we converted an unordered list of elements into a horizontal set of links.
So you might want to do something similar for this assignment. For example, working off of that example, you might want to set up the XHTML code for this global navigation to be something similar to this:
<div id="global_nav">
<ul>
<li class="selected"><a href="#">Recently Opened</a></li>
<li><a href="#">My Ratings</a></li>
<li><a href="#">My Friends</a></li>
<div class="clear"><div>
</ul>
</div>
Of course, you’ll then have to work on the CSS. For this example, you will want to use background-images behind each of the list items to give it the red or black background.
The sort options allow the user to order the listings shown on the page in a variety of ways.
You will want to be able to apply the proper colors and styles to the links inside of this section, as well as make the “Recently Opened” link look “active”, i.e. bold.
So you would structure your XHTML in such a way that the whole section is contained within its own <div> tag, and the links are within <a> tags. The “active” link simply has an “active” class applied to it, which allows you to add special styles to that link in the CSS.
<div id="options"> Sort Listings by <a href="#">Venue Name</a>, <a href="#">Top Rated</a>, <a href="#" class="active">Recently Opened</a> </div>
As with the selected element in the global navigation section, we can use a special CSS selector to make the link with class “active” look bolder than the other ones.
The listings of venues should be a table with one row for each listing. Each row is divided up into several table data cells.
As you can see, each table data cell has a few pieces of content.
Here is an example to give you an idea of how you might code the XHTML for one such row. You do not necessarily have to do your rows exactly like this, but it should at least give you a starting reference point:
<tr >
<td class="namecell">
<div class="name">
<a href="#" >Travertine</a>
</div>
<div class="location">
<a href="#" >Nolita</a>
</div>
</td>
<td class="typecell">
<div class="type">
<a href="#" >Restaurant</a>
</div>
<div class="subtype">
<a href="#" >Mediterranean</a>
</div>
</td>
<td class="goingcell">
<div class="going">
<div class="checkbox_container">
<input name="going" type="checkbox" class="going_checkbox" >
</div>
<label class="going_here">I'm going here</label>
<div class="clear"></div>
</div>
</td>
<td class="ratingcell">
<div class="user_rating">
BB User Rating: 0
</div>
<div class="ratebox">
<a href="#" >Click here to rate!</a>
</div>
</td>
</tr>
The pagination section towards the bottom of the page is conceptually a list of page numbers.
And you know that a list should probably be created in code using the <ul> or <ol> tags, as we saw with the global navigation.
Here is an example set of code that could potentially be used to create this pagination section:
<div class="pagination"> <ul> <li class="current"><a href="#">1</a></li> <li><a href="#">2</a></li> <li><a href="#">3</a></li> <li><a href="#">4</a></li> <li><a href="#">5</a></li> <li><a href="#">6</a></li> <li><a href="#">7</a></li> <li><a href="#">8</a></li> <li><a href="#">9</a></li> <li><a href="#">10</a></li> <li><a href="#">Next</a></li> <li><a href="#">Last</a></li> </ul> </div>
The list item with the class=”current” could be styled differently so that it appears to be “selected with an overline or top border.
September 29th, 2009 § 0
In today’s web development environment, and in software development in general, there is a popular principle of separation of presentation and content. In terms of web development, this would mean that the contents of a web page should not be dependent upon the style or design of how that content is displayed on the page.
In some ways, this is a question of efficiency. Until the last few years, a website’s style was completely and permanently interwoven with its content. The parts of the code that conveyed the meaning of the site, i.e. its text, were coded in such a way that they also were intermingled with code that indicated how that text should look, what font it should be displayed in, what color, etc. Thus if someone wanted to change the style, they would have to also change the content, and sites were thus difficult to maintain.
In today’s web environment, where users can be viewing a website through one of many web-enabled devices, such as screen readers for the hearing impaired, mobile phones, set-top boxes, as well as the regular personal computer, separating the presentation of a website from its content allows developers to use the same content but present it differently depending on the device that is accessing it.
By separating presentation from content, an iPhone user, for example, may see a version of a website that is optimized for a small screen, while a Mac laptop user would see the full-size version. They would both see the same content presented in different ways. You can imagine that a visually-impaired user could also benefit from a different presentation of the same content.
This is the fundamental principle that we, as trendy web developers, will try to apply to our usage of XHTML and CSS code. We will make every effort to use XHTML code purely for the content of our web pages. And we will use CSS code to indicate how that content should be presented.
We will also do our best to keep CSS code in separate files from our XHTML code, so that the two are not mixed and mingled. Our CSS code will be kept in files with a “.css” extension, while our XHTML code will be kept in “.html” files.
This all sounds great in theory, but the web is a messy place. Given the tools available to us today, the pure separation of presentation from content will not allow us to achieve the sophisticated visual designs we might want our sites to have. We will find that we must often structure our XHTML code in such a way that the CSS can easily make the page look the way we want it to, thus making the one somewhat dependent, or at least influenced, by the other.
Furthermore, this separation is predicated upon the notion that a site’s design has no importance to its meaning. One could argue that many sites, especially heavily branded sites, rely primarily upon visual impact to impart their message. The idea that a message is conveyed solely or primarily through text with no reliance upon presentation is to ignore the complexity of social interaction, and this principle probably says more about the people who profess such things than it does about technology.
But despite these shortcomings, as things stand today, there are still practical benefits to separating presentation from content as much as possible. Although it is awkward at first, one gets better at it with practice, and it does save time and make maintenance of sites easier in the long run. So you should do your best to separate content from presentation by using XHTML to demarcate your content, and CSS to indicate styles for the presentation of that content.
September 26th, 2009 § 0
Your homework for this week is to complete the wireframe diagram assignment we began in class.
Next week, we will begin to convert these diagrams into real web pages written in XHTML, so it is important that you complete your diagrams to your satisfaction, and then go through the following XHTML tutorials prior to next class:
And please familiarize yourself with the class syllabus.
You should also read at least once through the following information, which we will cover many times over. It is critical in the understanding of the web and web development:
Typical workflow for web development
Loading a web page sends multiple requests to the server
If you are a Mac user, you will want to take a look at the recommended equivalent software for Mac development.
July 15th, 2009 § 0
Inline elements take the shape of whatever content is inside of them. They stretch to fit only the width of the content inside of them, not any more. And they do not break the flow of the page with automatic line breaks.
Here is an example file highlighting the shape differences between a div and a span. Divs are block elements, while spans are inline elements. In fact, <divs> and <spans> are identical in all other ways except this difference.
It is possible to convert a blog element into an inline element and vice versa using CSS. You simply adjust the display property of the element in the CSS.
Here is an example where we have converted an element that normally has a block display into one that has an inline display by overriding the default display setting in the CSS code.