Application Design in PHP: A Real-Life Example
This chapter is from the book
This chapter is from the book
This chapter is from the book
Prevent trouble before it arises.
Put things in order before they exist.
The giant pine tree
grows from a tiny sprout.
The journey of a thousand miles
starts from beneath your feet.
Application design is a topic so broad that a whole book couldn't fully cover it. The term application design contains merely every single part of development, from data structure layout, flow charts, and entity-relationship diagrams to code layout, documentation, and anything in between. Because it is so important, however, we decided not to exclude it from this book, but instead to tackle a discussion of application design by restricting the topics covered to a "hands-on" example, namely phpChat. This chapter will give you an in-depth view of this real-time chat server application implemented in PHP, similar to an extended software case study. We hope that you can extract useful information and methods to use when designing your next application.
Many of the boxed notes in this chapter contain remarks about techniques common to application design that you should memorize and try to use directly on the suggested example (or phpChat in general), and indirectly on your next project.
Note: Another, more theoretical but shorter discussion about application design can be found in Chapter 7, "Cutting-Edge Applications."
Project Overview
When designing an application, you start with the idea of what the application is supposed to do. In the case of phpChat, the application is supposed to provide a browser-based chat service.
The chat should have the following features:
-
Real-time chat. No deferred relaying of messages and no refreshes.
-
No client-side programming. The browser should be confronted only with pure HTML (and eventually some JavaScript).
-
Networkable. It should be possible to link chat boxes.
-
Generic. Make as few assumptions about the target systems as possible and introduce as few requirements as possible.
-
No design enforcements. Separation of code and page layout.
-
Easy to use and administer.
-
Unlimited number of clients and chat rooms.
Once you've gotten this far and know what your application is supposed to do, you have to evaluate the concept and create a more detailed overview of how the application should be laid out.
Take the time to write down all the requirements. It helps a lot, especially as a reminder later on.
When designing an application with a customer, this step is called creating the specifications (or just specs). At this point, the customer can still influence the layout of the application. This is very important because the application must meet the requirements listed in this step, or it won't be approved by the customer.
The Customer Is Always Right, Even When He's Wrong
Customers who contract you for an application often do not have enough expertise to design such an application by themselves, which is why they hire you. When discussing requirements with customers, guide them when they're suggesting bad solutions. For example, if the customer says, "I want a chat that displays full-screen images of every chatter, refreshed at least every second," you might make this counter-suggestion: "Wouldn't it be better to try to stick to thumbnail views next to each line? Most of your chatters won't have enough bandwidth to display full-screen pictures at all."
But be careful; never insist on your point of view (except when customers want you to implement unrealistic features). After all, customers pay you to implement their vision. To avoid losing a contract, you may have to accept temporarily implementing a bad solution (when you see that you can't talk the customer into doing it the right way), and then later on change it when the customer sees that it won't work out using their strategy.
For this project, you will take the role of the project manager and the authors will be your customers. Since we're nice customers, we won't keep insisting on nailing down further details of this application; we'll leave the rest of the design to you. Whenever this chapter hits a point where a choice or decision can be made, sit back and try to make your own choices. Closely evaluate all facts and then compare your results with the conclusions discussed in the book.