When you're approaching a framework with a learning curve as steep as ZF, it's easy to be overwhelmed by new terms and declare them buzzwords. Instead, they have often a very precise meaning. I've creates this glossary to collect all the defined terms I could find, so that the PHP developer new to Zend Framework would have a place to come and lookup in the time of confusion.

He breaks it up into a few different sections - generic/reused terms, common component names, what MVC and the bootstrap are as well as the different parts of Zend_Forms.

The confusion lies in the purpose of the NDA, and the scope of what it covers. The branch's development will not be under NDA, nor will discussions between the deputies and the community, how they receive code submissions, what they reveal to others about their own plans, and so on.

The NDA does, however, cover any discussions that might be had with the EllisLab group about the structure and guidelines concerning the development of the branch. It's not designed to keep the community out of the development process but rather to keep things about ElliLab's other products out of the larger flow of ideas.

Especially when first getting started with various web development languages, it can prove to be a difficult task to learn all of the various naming conventions from language to language. This can be even more confusing when developers disagree on what's considered best practice. To help ease the transition for beginners, this list will describe some of the more common conventions.

Some of the conventions that they mention that are more specific to PHP developers are underscores before property names, uppercase constants, capitalized first letters in variables and alternative syntax (like ternary).

From the original comments made by Bernard Sumption:

All of the pain caused by inheritance can be traced back to the fact that inheritance forces 'is-a' rather than 'has-a' relationships. If class R2Unit extends Droid, then a R2Unit is-a Droid. If class Jedi contains an instance variable of type Lightsabre, then a Jedi has-a Lightsabre.

Travis agrees and then comes back with his second post to clarify something - composition versus inheritance:

I approach OOP from a flexibility standpoint with one of its biggest flex-points being loose coupling which in turn promotes reusability. I'm going to use Event as a hypothetical example.

He uses Events and design pattern illustrations (like the Visitor and Observer) to help illustrate his point.

From time to time I get the question why I recommend enabling open_basedir and on the other hand call it a solution flawed by design. This is actually a good question, because the untrained PHP user might get a little bit confused about this and might believe that I change my opinion on a daily basis.

He talks about his reasoning - how it does it's job protecting PHP developers from being able to get to those file, but how it's also flawed with issues due to some 3rd party libraries that have their own problems.

imagerotate has special intern functions when the rotation angle is a multiple of 90 degrees, it actually only flips the image. The operation is quite fast as it is a two nest loops with a little copy operation. However it looks like the manual has a little mistake in the function description, which can lead to confusion.

The problem comes from a part mentioning the scaling down of an image to fit into the destination image. With a flip of 90 degrees, though, the resulting image contents will stay the same size as the original - the image only flips, not really rotates.

She describes what they are with an illustration using a simple PHP script and breaking it out into the compiled version's parts - both in PHP4 and the PHP5 versions. Of course, representing what they are needs a flipside, so she presents a look at what they are *not* as well. There's also a brief mention of the special status that globals and static variables get outside the norm.