I guess I missed the Zend PHP Framework webcast on Friday. I was looking forward to it, but I signed up a while ago and forgot about it. By the time I got the reminder email, it was too late. Fortunately, the recording is now available. If you have an interest in ZPF or frameworks in general, you should watch this.
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.)
Feed
Subscribe to this blog…
Static methods will be alot nicer once we get late static binding in php6. Aside from that I also do not think that the monolithic distribution makes sense if they also want to sell themselves as providing solid components. So I think static methods will soon shed some of their inflexibility in relation to inheritance.
I have chosen to use a monolothic distribution model for my WebBuilder2 framework mainly because the things I stick in there are either PEAR packages are highly specialized packages where I did not spend a second thinking on how other people could make use of this outside of my framework.
Anyways .. I am going to listen to the podcast now …
Hi Jeff,
I’d love to see an example that illustrates how the use of static methods can come back to haunt you. I’m not involved with the development of the controllers, but I’m curious.
Or, perhaps you can just elaborate? I know you have a lot of experience in this area, so I doubt your comments will fall on deaf ears.
I happen to agree with the decision to distribute the Zend Framework as a single entity. I think Andi’s comment about a stripped-down version was just to point out that there’s very little benefit. If you have fewer components, all you really save is a tiny bit of disk space (and a handful of inodes). It’s sort of why I used to always choose the “full install” option when installing Red Hat – I figured I would only run what I needed, but it was nice to never need something and not already have it.
One inflexibility of statics is the problem that you cannot override them, so you lose inheritance flexibility there.
Suppose you have this:
// not using statics:
$db = &someDbFactoryMethod();
$db->connect();
The factory can be extended to return a driver of choice, and connect would be called on the object in question.
// using statics:
db::connect();
There is no easy way to implement a specific version in a derived class and have that called instead. You would need to modify the calling code by changing it to specialdb::connect, for example.
Another argument; suppose you have static methods because your object doesn’t have any state. Now at some point, you make changes that require you to keep track of state, so you would want to work with actual instances. That’s not possible without modifying all calling code.
Chris,
This was a quickie post and I just knew someone was going to ask me to elaborate on that part. Give me a little while to collect my thoughts and do some research and I’ll dedicate a full post to the topic. There are some pretty good points in the other comments here.
Heh, don’t we all
I’m still uneasy about the way they talk about code “found on the net” as possibly being unsuitable for commercial use (php itself can be found on the net, I believe…). It would be unfair to create a general sense of doubt which could harm well-written, non-Zend frameworks and I really wouldn’t like to see this being used as a main marketing point unless it’s very carefully qualified.
I’ve also been toying with a search engine supporting google-like queries: I don’t know whether to be miffed at being beaten to the punch by ZSearch or pleased since it might save me some work.
[...] I enjoyed Friday’s pro::PHP podcast interview with Andi Gutmans. With a name like pro::PHP how can I not like it? This was a less formal presentation than the Zend Framework webcast. Perhaps surprisingly informal for Andi, at least at the end. I thought Marcus Whitney did a great job selecting and asking questions. There were some technical difficulties in the live version. I hope those are worked out for the next broadcast, which I am looking forward to. [...]
[...] Stefan Koopmanschap hat in php|architect einen Artikel zum Loggen auf Applikationsebene veröffentlicht. Zunächst wird über die Theorie aufgeklärt dann folgt die konkrete Implementierung mit der Zend_Log Klasse des Zend Frameworks. Das ganze fand ich sehr intressant da ich selbst bei einer aktuellen Applikation ein Logging System auf Applikationsebene implementiert habe. Irgendwie hätte ich den Artikel früher gebraucht. *g* Ãœbrigens ist es kein Problem die Zend_Log Klasse außerhalb des Zend Frameworks zu benutzen. Ich halte es darüber hinaus für Sinnvoll die Meldungen des PHP Interpreters für die jeweilige Anwendung in das Log Verzeichnis der Applikation zu leiten. So kann man die Meldungen leichter auseinanderhalten. Glücklicherweise sind die entsprächenden Konfigurations Variablen “PHP_INI_ALL“, also von überall aus zu setzen. Wobei die Log Verzeichnisse selbstverständlich außerhalb der aus dem Web verfügbaren Verzeichnisse liegen sollte. [...]
[...] Eichorn (among others) notices that active record can’t work as shown in the Zend Framework webcast. The syntax presented during the web cast is not possible in PHP because of inherited static [...]
[...] PHP PHP Programming, Web Development, PHP Advocacy and PHP Best Practices. « Zend Framework Webcast PHP Book sales trends versus Java and Ruby [...]
Have you thought about adding some sort of social bookmark buttons world wide web? At least you should add one for Digg, which belongs to the most important bookmarking sites, so we can digg you up!