“The bottom line is that security has been set back nearly six years in the past 18 months,” Alan Paller, director of research for the SANS Institute, wrote in an E-mail. “Six years ago, attackers targeted operating systems and the operating system vendors didn’t do automated patching. In the intervening years, automated patching protected everyone from government to grandma. Now the attackers are targeting popular applications, and the vendors of those applications do not do automated patching.”

I’ve advocated better web application installation for a while, but as a usability issue. Increasingly, it is also a security issue. Just another example of why I think the PEAR installer is important. (and why I hope Zend PHP Framework is released on a PEAR channel.)

Chris Shiflet and PHP Developer both have coverage of the webcast. The webcast even caught some attention from the Rails camp.

I won’t try to summarize the webcast here, but instead offer a few impressions.

I found the webcast to be interesting, although it didn’t really answer the primary questions I have about the structure of the front controller and form processing. ZActiveRecord, ZMail, and ZSearch are fine components, but my interest lies in the controllers because that is the area where there is the least consensus about the state of the art. One red flag for me was the suggestion of putting business logic in actions. Nothing but a high level overview was given of the controllers, but this perks my ears as an issue in MVC separation.

The coding standards emphasize not reserving global resources. The framework will not define functions or global constants, it uses exceptions and doesn’t reserve __autoload for its own use. This is very good. On the other hand, it seems to rely on static methods quite a bit, which I think can burn you over the long run if you are trying to offer a componentized architecture and can make code more difficult to test. I’ve been moving away from static methods as much as I can in my own code. Eventually, I always seem to regret using them. They lure you in at the beginning with the promise of simplicity and then they punish you later with their inflexibility.

I wonder how many of the components do their own “connection management” such as with the ZSearch::open (static methods again)? This strikes me as an opportunity for a general dependency injection mechanism. A technique that we are emphasizing more and more in WACT, but which I don’t think has reached widespread use in the PHP framework world.

One of the stated goals of the Zend Framework is to improve the PHP ecosystem. The webcast suggests that Zend PHP Framework will play well with others, allowing you to use the components independently, or for example use a different templating system with the framework. On the other hand, Andi suggested that all components will be distributed in their entirety. When asked if a stripped down version could be distributed, the answer was “Why would you want to?”

I don’t think a monolithic distribution mechanism will play well with the new ecosystem of components that is rising up based on the PEAR installer’s new channel capability. Eventually, the PEAR installer will move into the end user application installation space. To participate in this, ZPF should be available over a channel. I think a key success factor for the Zend framework will be the release of individual components via a PEAR channel.

It is much better to be able to declare dependencies on individual packages, rather than on one huge bundle of components. Monolithic distribution unnecessarily ties together the release schedules of packages that might otherwise have no common dependencies. Micro-packages on a PEAR channel are the future of PHP web application installation.

Overall, I think Zend is taking a good approach to the development of ZPF. I look forward to learning more.

Update: Just as writing tests is an important process element, because testable code is better code, I think that micro package releases are better than monolithic package releases from a process standpoint. The mere act of writing the components so that they can be independently released highlights unhealthy dependencies. This, of course, has to be tempered by an overall vision and cross-package duplicate code elimination. Two areas that have been challenges for PEAR with its political fiefdoms surrounding each package and one reason why PEAR is not a framework.

(P.S. Hurry up and release ZSearch. I want to use it.)

I’ve also seen some ill informed speculation that Zend PHP Framework will kill off PEAR. Um, not gonna happen. PEAR is a library, not a framework. Well, PEAR is a repository of libraries, not a framework. Well, I don’t know what PEAR is, but its not a framework.

What is a framework? I wrote a little bit about this in The value of MVC, but according the the GOF:

A Framework is a set of cooporating classes that make up a reusable design for a specific class of software. …

The framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate, and the thread of control. A framework predefines these design parameters so that you, the application designer/implementor, can concentrate on the specifics of your application. The framework captures the design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse, though a framework will usually include concrete subclasses you can put to work immediately.

A reusable design for a specific class of software? That doesn’t sound like PEAR. It does sound a bit like ezPublish. Is ezComponents a framework by this definition? I don’t know.

Sebastian Bergmann doesn’t see competition between ezComponents and ZPF, suggesting that you can swap and combine. Scanning the list of ZPF components and the ezComponents shows overlap. Can you swap out ZTemplate for ezComponents Template or ZInputFilter for ezComponents UserInput?

I applaud ezComponent’s use of the PEAR installer. I hope that Zend PHP Framework embraces the PEAR installer as well.

I didn’t find a “powered by PEAR” section on the PEAR website. Can anyone recommend some large, widely deployed end user oriented applications based on PEAR? I want to try going through the installation process in some challenging environments. I’m just trying to get a feel for best practices and potential problems with installing PEAR and applications that depend on PEAR.

pear install Calendar beta

instead of:

pear config-set preferred_state beta
pear install Calendar
pear config-set preferred_state stable