Designing the Application

Here we will determine the basic design of the database structure and the application architecture.

Most applications follow one or another design pattern. Loosely defined, a design pattern is a description of an established architecture for solving a particular problem. For example, a program that fetches data from a live feed and stores them in a database typically follows a pipes and filters architecture pattern. The program fetches data from the source through a remote connection (a pipe). This program probably needs to alter the structure of the data in order to accommodate the schema of the target database. Therefore, it acts as a filter. Once the information is in the correct format, it opens a connection (another pipe) to the target database and inserts the data.

The pipes and filters architecture design pattern has passed the test of time as a solution that works for this type of problem, therefore, programmers need not re-invent the architecture when building a similar application.

Our user privilege system, like most other web applications that involve a database back-end, follows a multi-tiered architecture design pattern. In this design, the various aspects of the application, such as its data, business logic, and presentation details, are separated into different tiers (or layers) of the program. A multi-tiered program may have any number of such tiers.

This architecture delivers the benefits of modular design. If a manager decides down the road to change a font to green, or to use WML instead of XHTML, the required code changes are localized to a single tier, without affecting the database or the business logic. If you are interested in more information on multi-tier architecture, have a look at Chapter 15. For our application, we shall start by describing the data tier.

Designing the Database Schema

Our program will handle two basic types of entities: users and privileges. The schema should therefore include tables to store data about the two:

User

Field	Description	Key
`username`	Unique user ID	Primary
`fullname`	User's name

Privilege

Field	Description	Key
`priv`_`id`	Unique identifier for the privilege	Primary
`description`	Description of the privilege

In a typical application, a user table would probably have many more fields, but since we do not know the specifics of the end-user application, we are trying to keep it light and simple here. The developers who implement our user privilege system can modify the User table as necessary.

In addition to these tables, we need a table to join the data from the other two. In other words, a table that keeps track of which users enjoy which privileges. We shall call this table, UserPrivilege.

UserPrivilege

Field	Description	Key
`username`	User's ID	Foreign
`priv`_`id`	Privilege's ID	Foreign

Designing the Middle Tier

The middle tier of our program shall consist of classes that simplify the use of our system by developers and scripts that allow users to manage privileges in the application.

Database Access

To access the database, we will use the database abstraction layer described in Chapter 17. Recall that the code for the abstraction layer is in a file called DB.php.

The Privilege Class

The Privilege class will contain the following properties:

Property	Description
`priv`_`id`	Privilege ID
`description`	Description of the privilege
`privilegeExists`	Boolean variable indicates valid privilege

The Privilege class will contain the following methods:

Method	Description
`Privilege()`	Constructor
`populatePrivilege()`	Populates the data for this privilege
`create()`	Creates new privilege in the database
`update()`	Updates the privilege in the database
`delete()`	Removes the privilege from the database
`getPriv`_`id()`	Returns the property
`setPriv`_`id()`	Sets the property
`getDescription()`	Returns the property
`setDescription()`	Sets the property

The User Class

The User class will contain the following properties:

Property	Description
`username`	User's ID
`fullname`	User's name
`privileges`	List of all privileges
`userExists`	Boolean variable indicates valid user

Maintaining the privileges array as a property of the User class allows us to keep track of the privileges each user holds, thereby obviating the use of a UserPrivilege class.

The User class will contain the following methods:

Method	Description
`User()`	Constructor
`populateUser()`	Populates the data for this user
`populatePrivileges()`	Fills the privileges array for this user
`addPrivilege()`	Grants the user a new privilege
`removePrivilege()`	Revokes a privilege from this user
`hasPrivilege()`	Determines whether user has specified privilege

Method	Description
`create()`	Creates new user in the database
`update()`	Updates the user in the database
`delete()`	Removes the user from the database
`getUsername()`	Returns the property
`setUsername()`	Sets the property
`getFullname()`	Returns the property
`setFullname()`	Sets the property

Application Logic

Two scripts will handle the maintenance of the Privilege and UserPrivilege information in the system: privilege.php and userprivilege.php. We will leave it to the developers who use our system to create their own script(s) for maintaining user information such as name, contact information, and passwords.

privilege.php

privilege.php is responsible for handling user activity regarding privileges, namely requests to create, delete, or modify privileges in the system. It contains the following functions:

Function	Description
`main()`	Flow control
`getPrivileges()`	Returns an array of all privileges
`save()`	Saves the selected privilege
`delete()`	Removes the selected privilege
`validate()`	Validates form data
`displaySelection()`	Generates page for selecting a privilege
`displayDetails()`	Generates page for selected privilege

userprivilege.php

userprivilege.php is responsible for handling user activity concerning the assignment of privileges to users. It contains the following functions:

Function	Description
`main()`	Flow control
`getUsers()`	Returns an array of all users
`getPrivileges()`	Returns an array of all privileges
`save()`	Saves the current settings
`validate()`	Validates form data
`displayUserSelection()`	Generates page for selecting a user
`displayPrivileges()`	Generates page for privilege assignment

Designing the Presentation Tier

Since this system is meant to be integrated into other applications, our main consideration in designing the user interface is to keep it as simple as possible. We shall try our best to only present the necessary form elements without any fancy layout or flourishes that the end developers might have to undo.

For our client-side code, we shall use very simplistic XHTML. By using only basic form elements, we avoid problems that may occur with older browsers, and by coding in valid XHTML, we ensure forward compatibility and avoid problems for developers who want their sites to contain only valid XML documents.

The two primary user activities in our system concern the establishment of the privileges in the system, and the assignment of the privileges to the users. The first task involves two screens. The first screen presents the user with a list of all of the available privileges. The user may opt to take no action ("Exit"), select a privilege, or create a new one. Either of the latter two options will bring the user to the second screen. Here the user may take no action, modify the privilege's description, or delete the privilege. Once the action is complete, the user should be returned to the selection screen.

The privilege assignment task also entails two screens. The first screen presents the user with a list of the available users. The user may opt to take no action or select a user. Selecting a user prompts the second screen. This screen lists all of the privileges in the system, indicating which ones are held by the selected user. The user may opt to make changes to the settings or leave without making changes. Either choice returns the user to the first screen.