Temporarily Out of Stock Online
As Web sites and intranets become larger and more complex, static HTML files hit their limits. In the first part of Web Application Development with PHP the authors explain PHP's advanced syntax like classes, recursive functions and variables. They present software development methodologies and coding conventions which are a must-know for industry quality products as well as to help making develop faster and more productive. This part covers also many standard algorithms for tree-structures, string sorting and searching. Part Two focuses on the concept of Web Applications (as opposed to single scripts) and gives much insight into user and session management, e-commerce systems, XML applications and WDDX.
About the Author
Till Gerken is a developer with over 10 years of experience in C programming. He has a strong background in creating high-performance multimedia systems and other medium to large scale, high performance projects. He currently works as freelancer for different companies. Tobias Ratschiller is a New Media Consultant in Italy, specializing in the creation of large scale dynamic Web sites. He has provided consulting and implementation work for some of the world¿s largest Web sites and has contributed to several other PHP titles. Apart from that, he teaches at seminars about usability, user interface design and content management systems. He runs http://phpwizard.net. Both authors have published Open Source PHP projects and technical articles for magazines like Internet World.
Read an Excerpt
Chapter 1: Development ConceptsBefore diving into PHP-specific issues, let's start from a wider point of view. Some issues apply to application development in general, regardless of which language you're using and on what platform you're developing.
When working on a professional project, it's very important that you think about what you're doing. Know your enemy-never underestimate him. Although your project isn't really an enemy, the point still applies. Know all your project's specifications, its target platform(s), its users, and never underestimate the significance of small problems that you haven't evaluated completely before moving on to other topics.
Judging from our experience, planning takes at least 50% of the development time; the bigger the project, the more thoroughly you should develop its outlines. This principle applies to contacting your customers and working closely with them on defining an overall project outline, as well as talking with your developers about defining a coding outline. The less effort you spend on consistency and maintainability, the sooner you'll run into problems when reopening old files and trying to fix bugs or add new features.
Planning time isn't necessarily proportional to a project's size. As an example, think about a search algorithm that you have to design. The application doesn't have to do more than basically crawl through a heap of information, extracting data according to a set of rules. Let's say that the data is already there, so setup and output won't require a lot of effort. The application will spend most of its execution time in its main searching loop.The loop probably won't even take more than 100 lines of code, but choosing or designing an optimal algorithm for an optimal loop could easily take a whole day This little loop might be the most substantial part in your design phase, while on the other hand you may create projects with a few thousand lines that have been thoroughly planned in less than a day.
Similarly, let's say you need a little script that lists all files in a directory You could hack it quickly so it would perform just this specific task, listing all files in a specified directory You wouldn't have to worry about it anymore-the problem's solved and you can move on to other tasks, leaving your snippet behind. But another strategy might be to take into consideration that at a later point-maybe even in a completely different project-you'll probably need a similar tool again. Just hacking directory listers over and over when you need one, each for its specific task, would be a waste of time. Thus, when first encountering such a situation, you should think about it. You could create a separate module from the directory lister, allowing it to list different directories, optionally recursing subdirectories, eventually even accepting wildcards. You might create a bulletproof little function that would handle most special cases and also handle everyday demands to a directory lister just perfectly. With this latter method, after a few projects you would have a library of solid tool functions that you could reuse safely and rely on, and that sometimes might strip down development time significantly.
Of course, an ever-increasing number of freely available tool function libraries exist, but these will hardly satisfy all your needs, nor will they be optimized for your special demands. Some libraries are also just too heavy to carry around-having to parse a few hundred kilobytes of extra code every hit might significantly decrease the performance of your site. In this situation, it pays to be able to replace a sub-optimal solution with a 100% optimal solution that you created.
Larger projects offer even more opportunities for problems due to lack of planning. Late in development, you might encounter difficulties that you didn't or couldn't foresee because of the lack of work and time spent on the design. These difficulties might be so severe that they require you to completely restructure the entire project. Imagine a database-backed application that relies on an additional database abstraction layer. The database abstraction layer accepts only textual data, but at a later point you notice that you also need it to accept numeric data. You might enable it to accept numeric data by workaround conversions, but at a later point discover that the workarounds don't satisfy your needs. The only thing you can do at this point is change the database interface, which requires a rework of the abstraction layer as well as a check of all calls to it in the main code-and of course the removal of the previously created workarounds.
Hours or days of work spent on something that could have been avoided from the very beginning-problems that often decide between success or failure, because time is the most valuable resource that you will never have enough of.
The following sections guide you through most of the very basic, yet very important practical issues of development: improving your code quality as well as basic design and documentation issues. After covering these, we create an application programming interface (API), taking the naive, practical approach to familiarize you with the new concepts, followed directly by an API creation from scratch, developing it theoretically "on paper" and then nailing down a few practical principles to help you implement your next API-matters of style, do's and don'ts, as well as a few tricks of the trade.
What's the difference between good code and bad code? Actually, it's very simple. Good code-really good code-can be read almost like a book. You can start anywhere and at once you know what the lines you're reading are used for, under which circumstances they're executed, and any setup they might require. Even if you lack background knowledge and encounter a sophisticated and complicated algorithm, you'll at least be able to see quickly which tasks it performs, and under which aspects it performs them.
It would be easy to simply show examples and say, "Do as they did," but we'd like this chapter to impart a solid basis for writing professional code-a basis that makes the difference between truly well-crafted code and an everyday hack...
Table of Contents
I. ADVANCED PHP.
1. Development Concepts.
2. Advanced Syntax.
3. Application Design: A Real-Life Example.
II. WEB APPLICATIONS.
4. Web Application Concepts.
5. Basic Web Application Strategies.
6. Database Access with PHP.
7. Cutting-Edge Applications.
8. Case Studies.
III. BEYOND PHP.
9. Extending PHP 4.0: Hacking the Core of PHP.
Our rewrite of the language, and the huge amount of cooperative work that was put into a wide variety of function modules and sample code, pushed PHP beyond our wildest dreams and expectations. PHP is being used today on well over a million domains on the Internet, and is the tool of choice for server-side scripting in UNIX environments. PHP 4.0 is the next step in ensuring that PHP remains on the cutting edge of Web scripting technologies for years to come. The Zend engine (www.zend.com) revolutionizes the performance and scalability of PHP-based Web sites. Its integrated session support; built-in XML, Java, and COM support; as well as a bundle of additional features enable the Web developer to develop more powerful dynamic sites, more easily than everbefore.
With the continued development and integration of leading-edge technologies, PHP stays up to date. The new Java and DCOM support, the advanced XML features, and the improved OOP features further increase PHP's acceptance in business environments and make PHP a viable tool for enterprise computing. The commercial addons from Zend Technologies-for example, the debugger, IDE, and compiler-will lead to a further leap. Also, the insides of PHP 4.0 have gone through architectural revolutions that will be largely unnoticed by the end user. For example, the Web server interface has been completely abstracted, allowing the support of Web servers other than Apache. Books like the one you're reading right now provide you with the necessary background to utilize these new technologies successfully.
In my opinion, the future looks bright for Open Source in general and PHP in particular. In 1997, you had to jump through hoops just to convince your manager that Linux was at least as stable as Windows NT, and using Open Source in large companies wasn't even considered. The world has changed. Companies that took the mission to back Linux-based solutions, such as RedHat, SuSE, and VA Linux, have not only become commercial giants, but also positioned Linux and Open Source in general as an acceptable solution in every company today. Luckily, these companies were smart enough to do that while keeping the Open Source spirit and a strong relationship with the community. The Open Source development model on one hand, and the firm commercial backing on the other, brought Linux to unimaginable heights. I'm sure that commercial companies that take the mission to back PHP such as Zend Technologies, will help in making PHP an even more widely used solution, especially in the highest-end Web sites.
I would like to take this opportunity to thank Prof. Michael Rodeh of IBM Haifa and the Technion Institute of Technology, who encouraged Andi and me to cooperate with Rasmus Lerdorf, the author of PHP/FI 1.0 and 2.0; Rasmus Lerdorf, who was very happy to cooperate with us to make PHP 3.0 the official PHP/FI 2.0 successor; The PHP Group and the entire team of PHP developers, without which PHP wouldn't have been the excellent tool it is today; and finally, the PHP community, which has proven to be an endless resource for ideas and support.
I'm sure you'll find this book helpful when learning about advanced PHP and the development of Web applications. This is one of the few books covering more than the mere syntax of a language-it introduces you to the concepts behind the language, and can help you to enhance your problem-solving skills in Web programming.