Building Dynamic WebsitesWith the MVC PatternACM Webmonkeys @ UIUC, 2010RecapA dynamic website is a website which uses some server-side language to generate HTML pagesPHP is a common and ubiquitous server-side language, but there are many options Imagine if you wrote a program in Java which, instead of outputting unformatted text to the console, output HTMLAny language at all can be used to generate static pages, so long as the web server is configured rightParts of some big websites (e.g. Google) even use C++ for speed-critical tasksRevisiting PHP: ClassesA class is a definition of an object, which is a data structure with associated properties and methods.A class must be instantiated into an objectClasses in PHP work very similar to how classes work in C++ or Java.class MyClass { var $myvar; // Remember, variables are dynamically-typed. function doSomething($str) { $this->myvar = $str; }} Take note that $this is the reference for the object which doSomething was called on -- the arrow syntax (->) is how one accesses a method or property of a class.Working with objectsTo instantiate an object, use the new operator:$myobj = new MyClass(); To call a method (or access a variable) of a class, use an arrow (->).$myobj->doSomething("blah");$var = $myobj->myvar;Note how the $ is not repeated.You don't need to explicitly delete objectsPHP has automated garbage collectionWhy bother with classes?Classes provide a way to organize your code into separate pieces.You can avoid duplicating code by inheriting methods from superclassesWrap functional parts of your code into "black boxes" -- that is, provide an interface for other code to use but don't concern them with the detailsBut how does this apply to websites?Key point: programming a large website is not very different from programming a large desktop application. How can we apply the techniques we learn in CS to websites?First, analyze what a website doesA non-trivial dynamic website will probably, upon receiving a request from the user for a page, do the following:1. Determine what the user wants to do (view a list of products, view product details, buy a product, etc.)2. Find the data relevant to the task (from a database!)3. Potentially manipulate or modify the data4. Display a result to the userThe direct approachThe direct approach is to create a different page for each task, and implement those four steps on each. So we might have:welcome.phpproduct_listing.phpproduct_details.phppurchase.phpThis lets us know what the user wants to do fairly easily (just by virtue of which page we're on).However, there's still a lot of common code between each page. For example, the outer frame of the site's layout isn't changing.DRY: Don't Repeat YourselfA term used frequently in the Ruby on Rails community is DRY: Don't Repeat Yourself.In other words, eliminate redundancies from your code.If we have the same header and footer on every page of our website, what if we need to make a minor change?Need to change every single file in the same way!A real headache to maintain.If we want to avoid repeating ourselves, we should put all the common code for the header and footer in one place, like a PHP function, and simply call that function on each page.Factoring out the header, method 1:<?php // global.php// A library of common// functions for the // site.function header() { echo "<html>...."; // etc, etc.}function footer() { echo "....</html>";}?><?php // welcome.php// The homepage.include('global.php');header(); echo "Welcome to our site!"; footer(); ?> Pretty clean, eh?What about OOP?That approach works fine, but it lacks the logical separation that OOP can give us.Not that the previous approach won't work, but for larger sites, it can get messy.What if we wanted to turn each page into a class, all of which extend from a superclass?The superclass can worry about how to print the header and footer.All each class has to do is override the printPageContent() method (for example).So we define a superclass:class Page { function header() { echo "<html><body><h1>My Site</h1>"; } function footer() { echo "</body></html>"; } function printPageContent() { /* Needs to be defined in subclasses. */ } function render() { $this->header(); $this->printPageContent(); $this->footer(); } }And each separate page looks like:class WelcomePage extends Page { function printPageContent() { echo "<b>Welcome to my site!</b>"; }}That's it -- the other functions are already defined in the Page superclass.To print this page, we do:$page = new WelcomePage();$page->render();So what's the point?The key idea is that we want to separate parts of the application into logical components, and minimize redundancies.In this simple context, it's largely unnecessary. For larger sites, it becomes more useful:Being able to render a page at-will (just by instantiating it and calling the render() method) lets us dynamically route URLs to different pagesIf two pages are similar, we can extend one from the other and reduce redundancyThat is, we can apply OOP principles to web pagesGetting dynamicSo far, what we've done isn't really any better than just writing static HTML files.For our example, we're considering a store's website, so how do we make it dynamic?Directly listing products could be done in static HTML as well.We can make it dynamic by storing the list of products in a database, and retrieving it on each page load.Saves time when maintaining the list of productsIn general, dynamic (changing) content is loaded from a database.Not always, but it's a very common case.Pulling data from a databaseAs we went over briefly last week, pulling data from a database is done by first running an SQL 'SELECT' query on the database, then iterating over the results returned.$qry = mysql_query("SELECT * FROM products;");while ($row = mysql_fetch_assoc($qry)) { echo $row['name'] . ", " . $row['price'];}The downside of this approach is that it relies heavily on:always using MySQLnot changing your database schemaWhat if we change the name of a table somewhere?potentially hundreds of queries to modifyCan we abstract database querying?Not easily: a database is simply a collection of tables, which in turn are a collection of data items.Unlike with pages, we cannot easily use OOP principles to clean up our database codeWhat we can do, however, is encapsulate the parts of our code that deal with the databaseThat is,
Unlocking...
or
We will never post anything without your permission.
Don't have an account? Sign up