Core Web Application Development with PHP & MySQL 149
jsuda writes "Core Web Application Development with PHP and MySQL is an intermediate
to advanced-level guide for programmers and developers. It bills itself as >everything
one needs to know about building robust database applications. That is a
bit of puffery but this is a comprehensive practical guide for designing and building
production-quality, database-enabled applications." Read the rest of John's review.
| Core Web Application Development with PHP & MySQL | |
| author | Marc Wandschneider |
| pages | 912 |
| publisher | Pearson Education |
| rating | 8 |
| reviewer | John Suda |
| ISBN | 0131867164 |
| summary | Fine strategic overview |
The author is an open-source platform expert and software developer. He comes from a background of working with standard desktop Windows-based applications and made the transition to building dynamic web applications. His experience in making the transition informs this book as a comprehensive explanation of how to use the various technologies that go into writing web applications. For those making similar transitions, this is a very fine presentation done by a thoughtful, systematic designer. For those already busy in the PHP/MySQL area, the advanced level of instruction is likely to be valuable.
The emphasis is on open-source applications, particularly PHP5 and MySQL in an XHTML/Javascript environment. But, beyond technologies, the author's focus is on the strategies and systematic approach one needs to design and implement successful web applications. He writes for an advanced audience which is already basically familiar with programming and XHTML. Those writing or planning dynamic web applications will benefit most from the book.
There are 33 chapters in five parts - basics of PHP, database basics, planning web applications, implementation, and sample projects. There are three appendices covering installation and configuration of PHP, MySQL, and other related open-source applications like Apache, a set of charts of database function equivalents among the leading database types - MySQL, Oracle, PostgreSQL, Microsoft SQL Server, and a short list of recommended reading.
This is a large format book of 912 pages, including index. My reviewer's copy is a prepublication version containing grayscale graphics and much white space, especially around the code snippets, making reading easy and comfortable. Although the material is high-level and technical, the writing seems light and casual. Wandschneider's writing style flows easily, never bogs down even with technical details, and the book reads much faster than one might expect.
Although the best part of the book contains the three start-to-finish sample projects at the end - a calendar system, weblog engine, and e-commerce store, the lead-in chapters are nicely done, too. Chapters 1 and 2 are about getting started in PHP. There is a brief comparison to perl and C++, but the bulk is about PHP terminology and programming concepts. Much is made of PHP5's new object-oriented features, but the discussions of that here (and in Chapter 4) was about the only parts which I feel needed more clarity - the rest of the chapters are very clearly stated and contain plenty of good examples.
Chapters 3 - 7 continue with scripting concepts like functions, classes, arrays, strings and characters. The discussion is not designed to instruct comprehensively about PHP itself but works on a higher level of showing how PHP interacts with MySQL and other technologies on an overall basis. You can get detailed PHP coding instructions elsewhere. Chapter 6 contains an unusually good discussion of character sets, usable for global applications, and provides instructions on configuring Unicode and multi-byte support for high-level applications.
Part 2, Chapters 8 - 12, take the same approach to MySQL and databases in general. They include discussion of basic terminology and concepts, designing and creating databases, storing and retrieving data, PHP-to-database connectivity, and advanced topics, like use of "transactions" and advanced querying.
Part 3, Chapters 13 - 17, deal with the server-side matters. Again, the level of presentation is not on comprehensive details of PHP, MySQL, and web services, but present a comprehensive overview to guide planning, design, and implementation. Here the author states overall design considerations of a website noting how to incorporate CSS, HTML, code libraries, user interfaces, and web services into a working dynamic website.
User management and security concerns are noted throughout the book and Chapters 14 - 17 deal specifically with validation, and software and hardware security, including tips on how to secure your server. These passages on security are some of the better and clearest written I've experienced in this area.
Part IV continues the systematic approach to website construction discussing error handling, debugging, cookies, and sessions (again some of the clearest explanations I've read), authorization, and data validation with regular expressions. Chapter 21 is entirely about globalization and localization that is, dealing with the fact that the Internet is global and that there is a need to deal with foreign language sets. There are tips on how to determine users' locations and how to script to account for different language sets, including Unicode.
Chapters 23 and 27 are about XML and are especially useful now that XML and XHTML are becoming the reigning protocols of dynamic web activity. There is an extensive sample of using XML to work with the Google API. Using XML with PHP is an advanced topic and it is only generally covered here, together with XML web services and SOAP. Other chapters cover the use of extensions to PHP, like PEAR, developing a coding "style", creating test suites, configuring PHP.ini, and more. The three working examples are extensively commented and contain complete code examples.
The book comes with a comparison CD-ROM containing all of the sample code, and versions of PHP5, MySQL, and Apache HTTP server."
You can purchase Core Web Application Development with Php & MySQL from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
What, no AJAX? (Score:5, Insightful)
Re:What, no AJAX? (Score:5, Insightful)
Multi-tier (Score:5, Insightful)
As some of you know, multi-tier applications have (at least) 3 tiers: Database, business-logic, and interface. Java guys know this better: Model-View-Controller.
I have implemented for my webapps an MVC framework, and maintaining them or modifying them is a piece of cake. It's so easy i get bored with it sometimes.
In comparison, recently I've had to adapt the OSCommerce 2.2MS2 (built in PHP) for one of our clients' store. Every single php file in it has database, business-logic and interface ALL MIXED. The only separation they have is wrappers around SQL functions (that's not true separation, but a mockery). Maintaining it is a LIVING NIGHTMARE.
So please do yourselves a favor: Study the MVC approach and implement an MVC framework in PHP. You can use any templating library you can find. (for database, i use an adapted version of phplib's sql library). This alone has saved me not hours, but weeks of work, and is worth ">everything" you could learn from that book.
Re:What, no AJAX? (Score:2, Insightful)
Most books like this are at least 1/3rd boilerplate. Learn to skim.
Core Web Development (Score:3, Insightful)
Ebay changes their site, a week before Christmas. These people are stupid. These people are astoundingly stupid. If you looked up STUPID in the dictionary it wouldn't have the eBay logo, but direct you to an encyclopedia which has more space to go on about their profound acts of stupidity, when they've been stupid, how they've been stupid and how they've often failed to repeal their stupidity or even learn from it.
They aren't the only guilty ones. Less is More and too often I've had to deal with sites poorly constructed, as replacedments for sites which worked quite well.
Probably more along the lines of programing and some Gee-Whizzy things, but every web programming book should dedicate a chapter on when and how to make changes and common pitfalls to avoid.
Re:Oxymoron (Score:5, Insightful)
Ya, I've heard that line of bs from mysql for about a half-dozen years:
- they said it when they didn't have transactions - and it wasn't true
- they said it when they didn't have unions or subselects - and it wasn't true
- they said it when they didn't have referential integrity - and it wasn't true
- they said it when they didn't have triggers, stored procs, and views - and it wasn't true
Now, they've resolved *most* of the problems, and it's *almost* true. Sure, you can build robust applications with it. Of course, you can build robust applications with msql as well - it's just the extra effort that is required to achive "robustness" when:
- silent errors and data corruption problems current and historical
- frequent deviations from ansi sql (comments, nulls, etc)
- simple optimizer that is notorious for performance problems on 5+ way joins
- if you're planning on having your app run at various isps, most don't support current version - leaving you stuck historical issues (no views, etc)
- lack of parallelism or partitioning features - giving it about 2-5% of the speed of oracle/db2/informix when it comes to large table scans (reporting, analytics, etc)
So, sure. You can build robust apps with it. But man, it is so much more work than using postgresql. Let alone db2 or oracle. Maybe this makes sense for somebody (asp model targeting large number of isps) where you can afford the economics of re-inventing the wheel since most isps are running back-level versions.
Now, this might change in two years. Assuming that MySQL comes up with a substitute for Innodb (no attractive options yet), simplifies their licensing, and resolves the most significant existing issues. Then yes, it will be a reasonable option, right up there with postgesql, etc. Until then save your licensing dollars for something better and freer.
Yuck templates (Score:2, Insightful)
Why? Because of maintenance. But templates are supposed to make it easier to maintain aren't they.
No. Templates are there to add another layer of complexity to an app. Seperating the html from the php so that the designers are not confused? Hire better designers. Easily allow you to modify the site?
Well yeah if you think changing the color is a modification that should be in the html (should be in css) then yeah.
Perhaps I only seen bad implementiations of templates but in my experience the end result was always that you could never tell wich part of the fucking site was controlling what and that even simple modifications meant you had to figure out the template engine being used.
In my experience sites either have tiny changes that can be done by the coder and designer working together in a good team OR should have been in css anyway. The big redesigns usually require a code change anyway.
Worse, I had to handle more then one site where the answer was simple, Oh you want that change, sorry no that can't be done in the template. Template changes is for cosmetic changes, not functionality changes. Most buyers of e-commerce sites just don't seem to realize it. They think template means you can change your website. Yeah, in the same way a skin can change your winamp/xmms.
Perhaps I just build my sites wrong, I tend to make the html and php far to intertwined with a lot of the html being build by the code not just the php filling in certain blanks.
Database abstraction is usually defended by how easy it makes it to switch databases without having to switch code.
Eh yeah right. How often does this happen anyway? Like the site redesign it just is not a frequent occurence. Worse you often find that in favor of abstraction they leave out nice handy features one database supports but nobody else. Mysql_return_id. Every handy and only done by Mysql.
Again perhaps it was just bad experience but I seen several cases where the abstraction layer used did not support this feature forcing me to code around it. Extra PHP code to handle stuff already in the engine. Oh I am happy now!
The company that insisted the most on the abstraction NEVER switched in the two years I was there. Extra code extra bugs for something that is never used.
Image this in the real world. Your car doors being welded shut because one day you might want to turn it into a race car. WTF?
What is my point? Well that theory and practice do not mix. Yeah I 3 tired apps are usefull sometimes BUT that does not mean every bloody application has to use it. Database abastraction is usefull for code that is certain to grow. 99% of websites do not. Templates are usefull when you know you will get a lot of requests for cosmetic changes that are to big to complex to fit into css.
As for the whole saving you hours of work deal. At how many hours cost? I once read a quote that went something like this, "Do not code for code re-use unless you know in advance you are going to re-use it at least 3 times. Else the time coding for re-use will simply not recovered".
It made a lot of sense.
Perhaps I am just allergic to buzzwords.
Re:What, no AJAX? (Score:3, Insightful)
But, as soon as the code stops working, you're stuck because you don't really understand what the code does. IMHO, this is just an instance of the "cargo-cult programming" problem. Yes, you can copy/paste a great application within the hour, but you lose maintainability and scalability, mainly because you have no idea what's happening behind the scenes.
Nothing really substitutes a good understanding of what you're doing. For that, you need to spend a little more time and energy than just copy/pasting code.
Re:Oxymoron (Score:3, Insightful)
The fact that every six months mysql comes out with a brand new, latest and greatest, we-honestly-got-it-right-this-time-for-real version doesn't give anyone warm fuzzies.
Re:My approach (Score:1, Insightful)
Finally! (Score:4, Insightful)
Really, this is just what we needed.
Re:Oxymoron (Score:2, Insightful)
I've never been a MySQL fan, but I do use it at work where I develop and keep up a website. It doesn't cost anything directly to us(our webhost keeps it up), and it is far more than aduquote to most things one can come up with.
Maybe it's not a F1 car or latest Audi, but even if it is rusty old VM the cost/use ration is excellent if one just needs to move from point A to point B. Maybe it doesn't accelarate from 0-100 mph quickly enough, or maybe it doesn't have the latest GPS navigation system. But most of don't need them either. Not all business needs need the ultra hyper new database that can do EVERYTHING. Most of real life needs are just fetching the information and getting it to the webpage.
Infact I'd argue MySQL has more features that most people ever really need from a database. Outruling a case where one would become a de facto database expert.
Re:Oxymoron (Score:1, Insightful)