<input message=â€ťtns:BabelFishRequestâ€ť />
<output message=â€ťtns:BabelFishResponseâ€ť />
That means thereâ€™s a function called BabelFish available to you. To call it you
need to create what NuSOAP calls a proxy object, which you do by calling a func-
tion of the soapclient object:
$proxy = $client->getProxy();
With that done, your local PHP program sets a variable containing the phrase to
be translated and an array containing abbreviations for the languages into which
translation is to be made. Each individual call to the Babelfish service goes through
the proxy object. The syntax for setting the variable looks like this:
$result = $proxy->BabelFish(â€˜en_â€™.$lc, $phrase);
The service is invoked, via the proxy object, with two arguments: the phrase to
be translated and the from/to language pair that describes the desired translation
534 Part IV: Not So Simple Applications
The seemingly redundant code in the foreach loop has a bit of fun with Babelfish,
highlighting the fact that a translation from Language A to Language B and back
again doesnâ€™t necessarily yield the original phrase! This results, among other
things, from the gendered nature of many languages. Suppose you start with this
phrase in English:
If I had a hammer
Babelfish translates it into Spanish like this:
Si tenĂa un martillo
If you ask Babelfish to translate that Spanish back into English, though, you get
If it had a hammer
This is because tenĂa can mean I had, you had, she had, he had, or it had (itâ€™s
only in the subjunctive that Spanish is this vague). Only Babelfishâ€™s programmers
know why the algorithm chooses it in this case.
Writing a SOAP server application
Sometimes, you just have to do things the hard way. Even though NuSOAP can
make the job a lot easier, the file simple.php does the work of a SOAP server man-
ually. It includes the code necessary to receive, parse, and evaluate SOAP requests,
and to send out correct SOAP responses. Up until now, youâ€™ve worked with clients;
they requested data from publicly available Web services on the Internet.
Much of this file should look familiar to you. It receives a stream of raw text via
an HTTP POST event and uses a combination of string manipulation and PHPâ€™s
built-in XML parsing capability to extract an argument (either CD or DVD). The pro-
gram kind of fakes a database lookup â€” you can put in actual code if you like â€” and
formats the â€śresultsâ€ť of the â€ślookupâ€ť as a SOAP response.
Thatâ€™s the interesting part. The PHP program has to take on all the responsibility
of properly formatting the SOAP response. Essentially, the whole SOAP response
gets packed into a single variable, which is then returned:
<t:Transaction xmlns:t=â€ťurn:CDSpecialâ€ť env:mustUnderstand=â€ť0â€ť>
Chapter 16: SOAP 535
This passage should look very much like the standard SOAP response you saw in
the theory sections earlier in this chapter. Itâ€™s all here: the namespace declarations,
the Envelope, Header, and Body elements, and the data-type designations describ-
ing the values that populate the Body.
This chapter covered a lot and in the process opened the door to a very exciting
new capability of PHP. Web services, as made possible by SOAP messaging, enable
you to extract information from the Internet without writing complicated text-
parsing routines or having to hope that the HTML your programs parse remains
formatted the same way forever. Web services are resources you can rely upon to
give you correct answers in response to correctly formatted function calls.
SOAP isnâ€™t that hard to use, either, thanks in large part to the NuSOAP classes
from NuSphere and Dietrich Ayala. NuSOAP handles the tedious work of managing
HTTP requests and responses between clients and servers, and of formatting the
XML in SOAP messages as required. It makes Web services under PHP simpler by a
IN THIS CHAPTER
â—† Introducing project management software
â—† Discussing the problems a project management application must solve
â—† Examining the database tables for a project management application
THE PROBLEM IS ALMOST NEVER the code. When youâ€™re developing a large application â€”
or any project really â€” the hairiest difficulties have more to do with people working
in teams than with any technical aspect of the job.
The program in this chapter aims to facilitate the process of collaboration
between people working on a project. It will keep track of deadlines and keep notes
on which person is responsible for which tasks in a project.
Determining the Goals
of the Application
For the purposes of this application, project management has to do with the division
of labor between two or more collaborators. We want them to be able to see whoâ€™s
responsible for what, to know when deadlines are (or were), and to view the contents
of files. As an ancillary function, this application also requires authentication, so the
software knows which user is which and can adjust its output accordingly.
The catalog of pages our project management program requires closely resembles
the list of requirements it must satisfy:
â—† The project management application must support user logins, and it must
keep track of users as they use the application across many transactions.
This makes session management a necessity. We use PHPâ€™s library of
session-management functions and objects, just as we did in other appli-
cations in this book.
538 Part IV: Not So Simple Applications
â—† Once users have logged in, they should be able to view the status of the
projects theyâ€™re involved in. Theyâ€™ll want to see which files they are
responsible for (own, in the parlance), when they are or were due to be
finished, what any revised expected completion dates are, and whether
any problems have been noted with regard to individual files.
â—† Users should be able to share files that are relevant to a project.
The pages are straightforward â€” as youâ€™ve guessed by now, we certainly didnâ€™t
blow the budget on a designer. Figures 17-1 through 17-5 show you some of the
main screens of the application.
Figure 17-1: Project home page
Chapter 17: Project Management 539
Figure 17-2: Edit Project page
Figure 17-3: Calendar view
540 Part IV: Not So Simple Applications
Figure 17-4: Add New Task page
Figure 17-5: Project Admin home page
Chapter 17: Project Management 541
Designing the Database
Key to this application is its database. Much of the work that the project-management
application does is essentially note keeping about which files fit into which projects,
where they are, who owns them, and what their status relative to established dead-
lines is. This information is the sort that databases like to contain for us.
The entirety of the project management information store is contained in a data-
base called projects. The projects database contains a number of tables, each of
which tracks various aspects of the project management mission. Figure 17-6 shows
the complete schema:
projects users user types
project user map
project_id files admin
Figure 17-6: The projects database
The values that can be assigned to users to dictate their privileges are contained in
the user_types table. The table contains an incremented integer field called
user_type_id that serves as the primary key, and a user_type field that contains
English words that describe the type of user.
542 Part IV: Not So Simple Applications
The SQL scripts that create the database and populate its tables initially put the
values â€śstaff,â€ť â€śclient,â€ť and â€śadminâ€ť into the user_type fields of three records.
The users table defines the people who are allowed to use the database, as well as
their usernames, passwords, and a bunch of personal contact information. The
fields in this table are as follows:
â—† user_id â€” An auto-incrementing integer used as the primary key
â—† user â€” The username
â—† password â€” The password
â—† user_type_id â€” An integer that matches the primary key of one of the
user type constants in the user_types table
â—† email, firstname, lastname, company, and phone â€” Strings representing
Project and task status