I’m using stored procedures for two reasons. First, they’re more secure, as they hide database details and create an interface that makes it impossible for hackers to adversely manipulate the database. Stored procedures also use a different permissions system, which is an added security benefit. Second, in the book’s example site, I use somewhat of an MVC (Model-View-Controller) approach, separating the data (MySQL), the visual interface (HTML), and the logic (PHP). (To be clear, the site does this without using Object-Oriented Programming or a framework.) The MVC design creates very clean, autonomous files (for example, there’s not an iota of HTML in the PHP scripts and the only queries run are along the lines of CALL stored_procedure_name()). Furthermore, the MVC-based site should scale well, as you can throw server resources at just the parts that need the most help. You can also apply specific caching techniques to each part of the equation.

I first wrote about stored procedures in the second edition of my MySQL: Visual QuickStart Guide, published in 2006, so some extra research was in order on what has changed since then. Along with the MySQL manual, I read a fair amount of MySQL Stored Procedure Programming by Guy Harrison and Steven Feuerstein. It’s a good book that I’d easily recommend (although it also came out in 2006). One of the book’s strengths is that, in the process of discussing stored procedures, it does an excellent job of explaining some of the internals as to how MySQL works. This includes discussions of optimizing any SQL query you might use, whether inside of a stored procedure or not (because the first way to optimize a stored procedure is to optimize the queries it runs).

I was also pleasantly surprised to find how efficiently stored procedures execute in today’s version of MySQL. Stored procedures were notoriously slow when they were first added to MySQL in version 5. But in tests on my computer (running MySQL 5.1.37), stored procedures executed from the command line often ran ten times faster than the procedure’s queries on their own. This is due to how MySQL caches stored procedures, no doubt. When the procedures were run from PHP scripts, the performance difference was even greater (in part because there’s less actual data for the PHP script to send to the database). So along with improved security and data separation, stored procedures today can offer a significant performance benefit.

This all comes at a cost, of course. Stored procedures put a lot more load on the database. Generally I’m an advocate of using the database server as much as you can, but you’d have to be aware of the potential that the database server becomes the bottleneck in your Web site. Second, to create and execute stored procedures, you’ll need a MySQL user with permission to do so.

If you’re not familiar with stored procedures, check out the MySQL manual, the aforementioned book, or search online. Or if you wait a couple of months, you can see them in action in my new e-commerce book!

I’ll leave it up to you to read the full article, but the gist of it is that if you’re using MySQL 5.0.37 or greater and using the command-line mysql interface, you can enable profiling to see exact performance numbers for the queries you run. You can even see the nitty-gritty details: everything MySQL does to run the query, how long each step takes, and even what CPU or memory usage was required.

Between the SQL Profiler and the EXPLAIN the command, you can quickly improve how efficiently your SQL commands execute, which will improve the performance of your Web application as a whole. And, in a surprising result, I found that the stored procedures I created ran much, much faster than straight SQL (this was on MySQL 5.1.37). Clearly MySQL has been taking great strides to improve the performance of stored procedures, which used to be notoriously inefficient.

• Selling access to content (i.e., selling virtual products)
• User management
• Content management via administrative pages
• Using PayPal’s Website Payments Standard system

There are instructions on the site for how you can access it and you can even download all the source code. There’s a form on every page through which you can ask questions or post comments. I welcome any and all feedback you may have!

I’m currently developing the second example site now, and will also make that publicly available when it’s ready. Thanks!

Looking at the employees example, you would likely have a departmentId value in the Employees table: a foreign key (FK) to store the id value from the Departments table, thereby representing the department that the employee is in. That’s perfect. The form generated by Yii, though, will create a text input for creating and updating the employee’s department:

<div>
 <?php echo CHtml::activeLabelEx($model,'departmentId'); ?>
 <?php echo CHtml::activeTextField($model,'departmentId'); ?>
 <?php echo CHtml::error($model,'departmentId'); ?>
 </div>

That’s not appropriate, of course. The department value for the employee must be a number and you can’t expect the user to know the primary key numbers of the different departments. It’d be most appropriate to turn that text input into a drop-down menu. That’s not hard to do:

<div>
<?php echo $form->labelEx($model,'departmentId'); ?>
<?php echo $form->dropDownList($model, 'departmentId', CHtml::listData(
Departments::model()->findAll(), 'id', 'name'),
array('prompt' => 'Select a Department')
); ?>
<?php echo $form->error($model,'departmentId'); ?>
</div>

And that’s all you need to do to get this to work. The dropDownList() method creates a SELECT menu. It’s associated with the departmentId attribute of this Model. The drop-down menu’s data has to come from CHtml::listData(). That part of the code says to fetch every Department, and to use the department’s id value for the menu value and its name value for the visible label. The final argument indicates a default prompt to give the menu. Since the Employees Model has a departmentId attribute, the framework will be able to handle errors, pre-select the right value on an update, and so forth. If you change the attribute label for departmentId in protected/models/Employees.php, you can make the prompt say “Department” instead. No problem.

A more complicated situation exists when there’s a many-to-many relationship between two Models, such as Posts and Categories, in a blog site. Because of the many-to-many relationship between these two, neither Posts nor Categories would have a foreign key to the other. Instead, a junction table (and Model) would be used. Let’s call that PostsCategories. The table itself would only need two columns: postId and categoryId.For each category that a post is associated with, there would be a record in this table.

On the form for adding (or updating) a blog post, you’d need to be able to select multiple Categories:

<div>
<?php echo $form->labelEx($model,'categories'); ?>
<?php echo $form->dropDownList($model, 'categories', CHtml::listData(
Categories::model()->findAll(), 'id', 'category'), array('multiple'=>'multiple', 'size'=>5)
); ?>
<?php echo $form->error($model,'categories'); ?>
</div>

That dropDownList() method will create a drop-down of size 5 (five items will be shown), populated using the list of Categories, and the user will be able to select multiple options. If you were to run this code, though, you’d get an error as Posts doesn’t have a categories attribute. But that’s easy to change…

In the Model definition, you identify the relationship to other Models within the relations() method. The relationship between Posts and PostsCategories could be represented as:

// protected/models/Posts
public function relations() {
    return array(
        'categories' => array(self::HAS_MANY, 'Categories', 'postId')
    );
}

Now Posts has a categories attribute, meaning that the above form code will work. In fact, you can also add categories to the attributeLabels() array to give this relationship a new label that would be used in the form. You can even add a rule to make sure this part of the form validates. This is an important enough concept that I want to repeat it: when you create a relation, that relation becomes an attribute of the Model.

In order for the creation of a new Post to work, you’ll need to update the Controller to handle the PostsCategories. Within the actionCreate() method (of PostsController), after the Post has been saved, loop through each category and add that record to PostsCategories. The beginning of actionCreate() would look like:

public function actionCreate() {
    $model=new Posts;
    if(isset($_POST['Posts'])) {
        $model->attributes=$_POST['Posts'];
        if($model->save()) {
            foreach ($_POST['Posts']['categories'] as $categoryId) {
                $postCategory = new PostsCategories;
                $postCategory->postId = $model->id;
                $postCategory->categoryId = $categoryId;
                if (!$postCategory->save()) print_r($postCategory->errors);
            }

Now, when a new Post is created, one new record is created in PostsCategories for each selected category.

We’re almost done getting this working, except we now need to think about the update process. There are two problems with what we’ve got so far: getting the form to select existing PostsCategories and handling updates of PostsCategories. The form has already been created and populated, but to get it to indicate existing selections, we need to pass along the PostsCategories values. You might think that you can just fetch all the PostsCategories records where postId equals the Model’s id (in other words, perform a with(‘PostsCategories’)-> retrieval), but you can’t. For the drop-down menu in the form to preselect the right values, the form needs to access an array of values, not an array of objects. To achieve that, add some code to the loadModel() method of the PostsController. This method is called for the update, delete, and view actions and just returns a single Model. The Model is loaded using:

$this->_model=Posts::model()->findbyPk($_GET['id']);

After that, within the loadModel() method, you can add this code to fetch the associated PostsCategories:

$criteria=new CDbCriteria;
$criteria->condition='postId=:postId';
$criteria->select = 'categoryId';
$criteria->params=array(':postId'=>$_GET['id']);
$postCategories = PostsCategories::model()->findAll($criteria);

That code selects all of the categoryId values from PostsCategorgies where the postId value equals this post’s id. Next, we need to turn those results into an array:

$categories = array();
foreach ($postCategories as $category) {
    $categories[] = $category->categoryId;
}

Now, $categories is an array of numeric values, one for each category associated with the post. Just add this to the loaded Model:

$this->_model->categories = $categories;

And now the form will automatically select the existing categories for this post.

The final step is to update the PostsCategories when the form is submitted (and the post is updated). This could be tricky, because the user could add or remove categories, or make no changes to the categories at all. The easiest way to handle all possibilities is to clear out the existing values (for this post) in the PostsCategories table, and then add them in anew. To do that, in actionUpdate() of the PostsController, you would have:

if($model->save()) {
    $criteria=new CDbCriteria;
    $criteria->condition='postId=:postId';
    $criteria->params=array(':postId'=>$model->id);
    PostsCategories::model()->deleteAll($criteria);

Then you use the same foreach loop as in actionCreate() to repopulate the table.

And that’s it. It takes a little thought getting all this going but these changes seem to work fine for me and I haven’t come up with a simpler solution yet. I hope this helps you with your next Yii-based project. As always, thanks for reading and let me know if you have any questions or comments.

Part 1: Fundamentals

Chapter 1: Getting Started

• Identifying Your Business Goals
• Researching Legal Issues
• Choosing Web Technologies
• Selecting a Web Host
• Using a Payment System
• The Development Process

Chapter 2: Security Fundamentals

• Security Theory
• PCI Requirements
• Server Security
• Using Secure Transactions
• Common Vulnerabilities

———————

Part 2: Selling Virtual Products

Chapter 3: First Site: Structure and Design

• Database Design
• Server Organization
• Connecting to the Database
• The Config File
• The HTML Template

Chapter 4: User Accounts

• Defining Helper Functions
• Registration
• Logging In
• Logging Out
• Managing Passwords
• Improving the Security

Chapter 5: Managing Site Content

• Creating an Administrator
• Adding Pages
• Displaying Page Content
• Adding PDFs
• Displaying PDF Content
• Recommended Alterations

Chapter 6: Using PayPal

———————

Chapter 1 is an overview of the process along with tips for making certain decisions, such as hosting. Chapter 2 is generally a big-picture look at security, along with what primary decisions (e.g., hosting, certificate types) you’ll need to make. At the end of the chapter, I discuss the most common server vulnerabilities and attacks and how you go about preventing those. Although the chapter is really about an approach to security, it has some exact recommendations as well. More specific security techniques are demonstrated throughout the rest of the book.

In Chapters 3-6, you’re creating a entire site for selling access to online content, in both HTML and PDF formats. You’ll learn some ways to automate processes and effectively separate out bits of code to make the site easy to maintain. I don’t do anything fancy with the HTML templates, the PHP, or the MySQL, but there’s some great application of those technologies (in other words, you’ll learn a lot but won’t be overwhelmed with stuff like Smarty, OOP, etc.).

In Chapter 4 I created some really great helper functions. I even impressed myself with their usefulness and simplicity. The chapter also handles passwords and form validation in very secure ways. Chapter 4 concludes with some other ways you can heighten the security of the system, when you deem that appropriate. Chapter 4, User Accounts, may be something you’re familiar with overall (perhaps from another book of mine), but I think I’ve added enough new ideas here to still give you some value for reading it.

In Chapter 5 you learn how to add content to the site. There are two types. For the first, you can add HTML content using a WYSIWYG editor, that I show you how to integrate. For the second, you can upload PDFs. The PDFs will only be served through a proxy script so that a user must be logged in (with an account that hasn’t expired) to access them. The chapter wraps with discussions of about six different features you could add to the site, almost all intended to make it a better site for the potential customers. Although I don’t walk through the every add-on in complete detail, you’ll see what other tables you’d need to create, what SQL commands might be involved, and how the PHP code would work. I like this addition to the chapter and hope you will, too.

Chapter 6 integrates PayPal. You’ll learn a bit about how PayPal works and what its strengths and weaknesses are. Then you’ll use PayPal’s sandbox to test your site and see what you need to do to take the site live.

Next week I’ll be starting on Part 3 of the book, in which you’ll create an online site that sells coffee (beans, not brewed). I choose coffee as a product for a couple of reasons. First, I love coffee. Second, it’s an example of a physical product that must be shipped, that has inventory, and that also has permutations–size, roast, whole beans/ground–without being too, too complicated.

So that’s where things stand. Thanks for your interest in the book and please share any questions and comments you may have!

The patterns are organized by category: layout, navigation, selection, rich interaction, and social. For example, there’s a pattern for showing the availability of a person (like you’d see in IM) and another for how breadcrumbs should be used. Mostly the patterns are descriptions of what you should do, based upon what’s best for the end user. Many of the patterns do have links to code examples, although those will often make use of the Yahoo! User Interface library.

Part of the design pattern library is a stencil kit, available for OmniGraffle (the program I use), Adobe Illustrator, Visio, and other applications. Using this kit you can quickly create a mock-up of the user interface. And being Yahoo!, all of this is available for free.