In this article I will demonstrate the power and simplicity of developing PHP applications using the WASP Framework through the illustration of a simple user module design pattern. The example code will encompass the creation of a user account and subsequent login validation. In the course of this discussion, we will cover the creation of the three tiers of the application– model, view, and controller–and introduce a simple approach to using AJAX to save application form data and present flexible user interfaces.

Introduction
If you’ve ever used an Internet application to purchase a book, buy a ticket, or check your e-mail, you’ve most likely encountered the ubiquitous user login page. Any sufficiently complex web application necessitates the creation of user accounts and the authentication of these accounts via some kind of user management module. Before a user can successfully log into an application for the first time, they must be presented with the opportunity to create an account. A user’s account data is typically saved in a database and used to validate against when they return to the application via the login screen. This is nothing new, and has been solved in many ways by thousands of applications. However, as I will describe later, this scenario is a good one for introducing complex application logic in WASP, and you will be able to see how simple and powerful it is to write code in such a framework.

The example in this article is written using the Open Source PHP 5 framework WASP. WASP is a powerful web application framework built on PHP 5. Frameworks have become popular in the web application community for their ease of use and ability to solve common problems quickly. WASP strives to allow web developers to make great applications with more fun and less code, but in the familiar playground of PHP.

To get the most of this article you should be familiar with PHP 5 and have a general understanding of the WASP framework. More information about WASP can be found by following the links at the end of this article.

Programming in Three Tiers
The Model-View-Controller software architecture design pattern has long been considered an optimal choice for enterprise software developers. Using the MVC approach divides your software into three separate, but related, tiers—one for the data model, one for the user interface view, and one controller to tie in event handling and business processes. With this separation, you are able to isolate changes in one part of the application from the others. For example, if you were given a new requirement that your application needed to support a PocketPC interface, you can add another View to support it, leaving your business logic largely unaffected. By keeping your application compartmentalized in the MVC style, you minimize the number of places in your code that are affected by an unforeseen requirements change, or even an unexpected bug.
The WASP framework for PHP was built with this architectural approach in mind, and makes it easy to write your own PHP applications in the MVC style.


The Underlying Model
The Model is the ‘M’ in MVC, and it is the abstract representation of the data the application interfaces. In most applications, the model is represented by an SQL-driven relational database and a set of business rule functions [or methods] defining how the data should be entered, retrieved, and deleted. The model layer in WASP adds a level of abstraction to the database that removes the need for common SQL queries, making it easier to save and retrieve data for your application.

For the sample application, I’ve created a database table called user that will hold the user account information for the application. The user table will hold the user’s name, e-mail address, physical address and phone number, and password. The SQL shown in Listing 1 will create the table for you.

Listing 1


Now that you have your database table created, this is a good time to set up your WASP application environment. Instructions for doing this are in the documentation and tutorials on the home page. Ensure that you have an Application directory and your build.properties file configured properly. After running the command phing db you should have a db directory with a UserWrapper.php class file in it. This is your auto-generated model for this example.

Edit the UserWrapper.php class file that was just created and add the code shown in Listing 2 to finish your model’s business methods (below the //##END_GENCODE line).


The validateSave() method gets executed by the framework when the save() method is called, and ensures all required fields are set. If not, an error will make its way up from the model, through the controller, to the view where the user will see it. You can see that the save method generates a new password for the user if the primary key has not been set (which can only happen if this is a new record) and sends it to them via e-mail.

The Simplicity of the View
The View is the layer that exposes the data in the model in a way that makes sense to a particular user using a particular interface. A sufficiently abstract view layer provides a means to separate the user interface from the business logic of the application, allowing for improvements and extensions of the interface without worrying about interfering with the underlying code. The view layer in WASP uses the PEAR Flexy template manager to render HTML pages.

With respect to our example, we will need to provide a view component to allow for account creation. Your application will need to present the user with a screen to collect their personal and credential information. The information collected should include the user’s name, e-mail address (which will be used as the login credential since it is guaranteed to be unique to a user), physical address and phone information. Other information can also be collected as needed by your application. Notably left out, however, is a password field. For this pattern, we have written code in our model to generate a password upon account creation and e-mail it to the user (via the generatePassword() method in UserWrapper.php). This ensures the user’s e-mail address is valid; otherwise, they will not be able to log in to the application because they will never receive their password.

In your WASP application, create a user module by running the command phing module and naming it user. Edit the user/templates/user.chunk so it contains the HTML shown in Listing 3.

Note that in WASP it is important that the names of the form fields in the template match the names of the columns in the user table, since the controller will pass these values to the model when the user presses the create button.

The Power of the Controller
The controller in the MVC architecture is the event handling glue that makes the application flow together. The UIModule and Chunk classes that determine page flow for a particular state of the application encompass the controller in WASP. In this example, there will be two states the module will care about: REGISTER and LOGIN. Edit the UserModule.php class in your user directory and make the code changes as shown in Listing 4.

Listing 2


The UserModule.php class above will handle the display of the UserIndexPage or the LoginPage depending on whether the user has been through the UserIndexPage’s account creation process or not. I’ll talk about the LoginPage class in a bit; for now, let’s work on the UserIndexPage.

I’ve already written the View for the UserIndexPage using the HTML detailed earlier. Now let’s write a controller class that displays that particular view. Edit UserIndexPage.php and give it the code shown in Listing 5.

The UserIndexPage class saves the data entered on the user creation page by listening for the create button’s press in the request at the line if (Request::getParameter(‘create’)). If it was pressed, the controller constructs a User model class and fills it using the form fields submitted by the user. The save() method is then called, and any errors found by the validateSave() method in the UserWrapper class are captured. If there are no errors, the user is redirected with the UserModule’s STATE parameter set to STATE_LOGIN, which [you’ll remember from the UserModule class code] causes it to draw the LoginPage.

Listing 3


Listing 4


Listing 5


Listing 6


A Touch of AJAX
Now that you’ve written the code to allow a user to register in your application and create an account, you’ll need to give the user the opportunity to login. As part of this example
Login pattern, I’m going to include an AJAX action to check for valid username and password. This isn’t strictly necessary for this pattern, but it illustrates how you would include AJAX calls in an MVC WASP application. To provide an easy way to perform AJAX calls, this example uses the Prototype JavaScript library. Download the package and place the prototype.js library file in your application’s user directory.

Now you’ll need to create the View for the Login page. Make a file in user/templates called login.chunk and add the lines of code shown in Listing 6.

The JavaScript function performAJAXLogin() is executed when the user clicks the ‘Login’ button on the page, sending the login information from the form back to the server. The result of the AJAX request is then handled in the handleResponse() function which checks for a redirect URL if the login was successful; otherwise, it displays an error message on top of the page.

You’re probably wondering how the server handles this request. It certainly is going to look different since it is not sending back an entire copy of the page. More specifically, when the AJAX call is made, the server instead only sends back an error message or a URL to send to a page redirect. Fortunately, the code to handle this is not as complicated as you might expect. In fact, it is surprisingly simple, thanks to the power of the WASP framework. Create a file in user called LoginPage.php and add the code shown in Listing 7 to it.

Listing 7


You’ll notice that the handleEvents() method operates as you would expect, except that in both the success and failure cases the code calls die(). Lets take a closer look—when the login button is pressed, a UserWrapper model object is created and filled with the e-mail address and password submitted via the AJAX request. The find() method is called to see if there is a user that matches the entered credentials. If so, the execution is halted, returning the URL of a module in the application to which the user will be redirected (in this case ‘Main’, but you can set it to any place you like). If no matching user is found the execution halts, returning only the error message in the response, which is displayed to the user without refreshing the page.

Conclusion
This example was provided as a representation of an interface design pattern for account creation and logins in MVC with WASP. You’ve constructed a user model class, complete with business rules specific to the creation of a user account. You then constructed a view to allow entry of user information, which is then saved to the model using the event handling of the controller. Finally you created an AJAX assisted login page, which allows the user to login or link to the account creation page if necessary.


By keeping the components of this pattern abstracted in an MVC way, it can be easily applied to your own web applications with minimal customization. The model can be incorporated into your own database schema, the view can be changed to match your particular styles, and the controller can be linked to the logic of the rest of the application.

About the Author

Brian Fioca has over nine years of experience in architecture, design, and development of enterprise solutions in Java, and has recently (somewhat to his surprise) become a champion for dynamic language technologies in the LAMP world. Over the years, he has contributed his talent to such companies as IBM, UPS, and Employease. Brian is the chief scientist and senior technical consultant at PangoMedia, Inc. based in scenic Anchorage, Alaska. He lives there with his lovely wife sans igloo or sled dogs.