We present some ideas on the process of Web application development using PHP and MySQL. These are our ideas only. Every developer (and teacher) has their own ideas. The ideas are affected by the platforms you work on.
These notes are influenced by the Anderson et al. text.
The best Web applications are collaborative (users provide much of the content) and personalised (for individual users' needs).
Again, some common features of these many types of applications include:
Designing the data model (relational, ER, UML, ...)
Users (name, address, email, password)
leading over time to ...
Users (name, address, email, password, home_phone, work_phone, mobile_phone, photo, biography, interests, ...)
Users (name, address, email, password)
Attributes (user_name, attr_name, attr_type, attr_value)
where the latter table might be defined in SQL as:
create table attributes ( user_name varchar(40) not null, attr_name varchar(40) not null, attr_type varchar(20), varchar_value varchar(200), blob_value blob, date_value date, primary key (user_name, attr_name) );(But we don't expect you to use skinny models in this course.)
Designing the transactions
Only use form elements that are required for the transaction. Avoid unnecessary form elements.
Designing the page transitions
Performing preliminary usability testing
Selecting the tools (mostly done for you in this course)
Implementing the designs
Performing further usability testing.
Iterate (implementation and design).
Transitions diagrams (sometimes called interaction diagrams) are important for both specification and design. A transition diagram is a directed graph with annotations on (some) edges. The nodes of the diagram describe page views and actions (that do not correspond to page views) in the application. Nodes should be labelled by verbs, e.g., show all users, enter new user details, add new user. The edges describe transitions between nodes. The start or home node should be identified.
Transition diagrams are important for specification. Developers can use a diagram to check that all requirements have been considered and that all required transactions have been identified, and that all transitions are appropriate.
A transition diagram may be implemented either (1) with a separate script for each node or (2) by a single (large) script that implements all nodes. Each approach has its pros and cons, but personally I find an implementation with many small scripts easier to manage. (However, scripts must be carefully and consistently named!) To support the design, nodes may be annotated with their file name (if approach 1 is used) and any included file names. Edges may be annotated with the variables whose values are passed in the corresponding page transition. Other annotations may also be useful.
Developers can use the annotated diagram as a guide to the actual implementation.
If a template system is used, a separate template file will probably be associated with each page view in the diagram. So, ignoring any file names provided, a single transition diagram may be implemented using one or many scripts, with or without templates.
Examples of transition diagrams are shown below.
Here is a very simple transition diagram for a one-component
implementation of the guestbook (without searching or pagination).
Note that it contains an action node (
enter.php) that does
not correspond to a page view, and hence is unlikely to suffer from the
Here is the transition diagram for a guest book application with searching but still without pagination. The transition diagram gives the file names for each page view, indicating that each page view is implemented by a separate PHP script or HTML document. The diagram indicates there is no transition from the search form back to the home page (requiring the back button to implement this transition). It also indicates that the "add new message" script redirects to the home page and thus avoids the reload-redo problem. The two nodes at the left may be implemented either by a single combined script (as suggested by the file names) or by separate scripts.
Note that transition diagrams describe specifications not implementations. Each node in a transition diagram represents either a page view (an HTML file or a PHP script that outputs an HTML file) or a one-component (i.e., action) script executed only for its effect. The two types of nodes must be clearly distinguished. Nodes do not need to correspond to files. For example, an application could be implemented either as one large, complex PHP script or with a PHP script and corresponding template file for each page view.
(These diagrams were drawn using OmniGraffle on Mac OS X. A student recommends SmartDraw or Visio for use on Windows.)
This simple example represents the core of Google Groups or Yahoo! Groups. It provides the ability to display titles of the discussion groups, to create new groups, to display headings of the messages in a group, to display the content of a message in a group, and to create a new message or reply to an existing message.
Here is a database design for the system.
The transactions for the system are already specified in the system description. Often the description is incomplete or unclear but here it is OK.
The page views will use unordered lists of groups and messages, description lists for individual messages, plain text lists of navigation commands, and minimal forms.
Here is a transition diagram that specifies the page views, actions and transitions of the system.
Here is an implementation of the system. This implementation uses a separate script for each page view and action in the transition diagram (names are not shown there), it uses MySQL function calls and included definition files, and it uses Smarty templates. It uses a combination of URL queries, session variables and hidden form elements to maintain state across page transitions.
Note that the specification and implementation are inconsistent: they redirect to different page views after adding groups and adding messages. Which redirections are preferable? Such decisions need consideration; they should not be made arbitrarily.
The text-only user interface for the system is minimal but could easily be improved without changing the underlying implementation.
Exercise. Extend the transition diagram to allow users to register, to require (registered) users to login before creating new groups or posting or replying to messages, to allow users to delete their own messages, and to allow users to search for messages with given key words in their headings.
Solution. Here is a possible solution to this exercise. It fails to capture the possibility that unlogged-in users attempting to create groups or add messages are automatically transferred to a login form and redirected back to the initial form after logging in.
Exercise. Extend the implementation to include the above features.
Here is a transition diagram that specifies a simple library management system (used as an assignment in 2006) that allows librarians to add books to a library, allows borrowers to borrow and return books, and allows all users to browse and search the books and browser the borrowers.
Again, the transactions are explicit in the system description and the page views use a simple text-only interface. (Note that this implementation uses the PDO library API so that it would be relatively easy to move this application to a database system other than MySQL. Note also that it does not implement user registration and authentication.)
Exercise. Decide how the selection on the "book details" page view could be generated.
Exercise. Modify the transition diagram to make user names on book pages links and book titles on user pages links. Extend the implementation accordingly.
This example is based on my experience with NAB's online banking system. It covers some core online banking features.
Users must login before they can use the system. They can view the balances for each of their several accounts. They can view recent transactions for each account, one account at a time. They can transfer funds from one account to another, including other users' accounts. They can view recent funds transfers from each account, one account at a time. They can view and update a list of BPAY billers. They can pay a bill from an account to a BPAY biller. They can view a list of recent payments from each account to BPAY billers, one account at a time.
There are many other functions not discussed here. THere are many details of these functions not discussed here yet.
Here is a possible database design for the system.
Exercise. Describe why this design is not in Boyce-Codd Normal Form. Discuss whether or not this is a problem.
Exercise. What (additional) transactions are unable to be performed with this design?
The transactions for the system are already specified in the system description above. Note that there are ambiguities and omissions. For example, "transactions" include payments from external sources to an account and bill payments, as well as fund transfers.
The page views will use unordered lists of accounts, billers, transactions, and payments. Accounts and billers will be links to details pages.
Here is a possible transition diagram for the system.
Exercise. What is the most important session variable that must be maintained in traversing this diagram?
Exercise. Extend the database design and transition diagram to include one distinctively different capability.
httpsprotocol must use absolute addressing.
Web Programming is programming.
Programming requires you to have a good knowledge of data structures and algorithms, to be good at problem solving, to be good at design, to be able to pay attention to details, to be very familiar with the languages and libraries you use, to be good at program testing and debugging, and to be conscientious and accurate in documenting your work. Phew!
Web Programming is not an isolated subject. To do it well requires mastery of database design courses, programming courses, data structures and algorithms courses, information security courses, user interface design courses and possibly multimedia design courses.
This implies that Web Programming is best done by a team of people with different skill sets.
We can't cover all these topics in detail here, but will expand on just one of the topics below.
This is a huge topic. Here are some initial principles.
This is another huge topic.
php script.php" command on the server command line frequently to detect PHP errors. (This doesn't happen so much with our current configuration.)
Suggestions for design, implementation, programming, testing and debugging techniques are invited.
Several new Web development frameworks allow development to be done at a "higher level". This enables developers to be more productive. But there is a steep learning curve required to become competent with the frameworks.
Often these frameworks are based on a URL-model-view-template pattern. To build an application, you specify the URL patterns used (cf. PHP scripts), the data model used (cf. database tables, but often now object-oriented classes), the views or functions required to process each URL pattern, and the templates required to implement each page view.
Examples of such frameworks include:
These are being increasingly frequently used, but it is too early to know which if any will come to dominate.