I just got done with the php|architect web case concerning the Zend Framework and I have to admit – there was a whole lot of content in there that answered a lot of the questions that I (and others in the community) were having about what the framework will really be and what kinds of things it’ll do.

I took some notes along the way of what the Zend folks talked about, and I wanted to go through it for those out there that didn’t get a chance to attend:

The Zend guys emphasized that the framework is more than “just another project” out there in the PHP arena – it’s more of a part of an “ecosystem” (as he put it) that resides around PHP. They had a puzzle graphic showing how it would all fit together and included other things like the Eclipse collaboration and community involvement. The framework is really just a part of all of this, and looks to make better, faster (and cleaner) PHP apps possible. Of course, their target is to make it the industry-leader, and to have a “vibrant user-base” that surrounds it, providing things like feedback, new component suggestions, and bugfixes for the framework’s code.

One of the keys to this whole thing is to keep it simple, something they really do seem to be trying to keep in mind. They’re looking for that “extreme simplicity” that comes from a good review process, tons of testing, the inclusion of modues/features that most people use, and providing good, easy-to-use documentation for the entire project. When they looked at creating it, they also didn’t want to cause any kind of conflict that could come with the use of someone else’s code, so they started from scratch, generating all of the code in-house. There’s a strict review and testing process that they have for the components as well before they can be included in the package. As far as licensing, they wanted to stick with the PHP crowd on this one and went with a BSD license, with “no strings attached”. When external code (or coders) are being considered to join the team, they sign off on a CLA (Contributor License Agreement) before anything is even considered.

Now we start getting down to the real meat of the matter – the architecture of the framework. Since the emphasis of the enture framework is that it all works well together, the “glue” that holds it all together needs to be solid. As a result, when a new release happens, the plan is to upgrade the entire package, not just parts. Of course, people can use the Zend framework for some things and mix-and-match with things like PEAR for others – it’s not restrictive. There are three main parts to the framework: the front controller, the action controller, and the component library interface. Of course, the front controller handles the incoming data and information and can act as a substitute for the mod_rewrite module in Apache (handles URI mapping). It also includes a plugin capability. The action controller includes an “action interface” that does most of the work that the front controller passes along. On the back side of this happy trio, there’s the component library interface – the manager of all things…well, component-ish. This is the part that tells the framework what components you want to use and how to use them with the data given. Some examples of these components include:

• Frontend – Ajax, forms, etc
• Data – ActiveRecord, InputFiltering
• Syndication – RSS, Atom
• Web Services – REST, SOAP, XMLRPC
• User – Auth, Session
• Documentation – phpDoc, Manual

This brings us to the next stage – the components themselves. Each of the components are developed by a team of individuals, no single developer/small teams here. Cross-company development is also encouraged. All of the components come out of proposals that are written up and “well reviewed” before they’re ever even talked about as far as inclusion. As mentioned before, all of the code for them is brand new stuff, not pulled from outside sources and is subjected to a good real-life testing before it’s finally approved. Some of the defaults that are built into the framework include the throwing of exceptions for all errors, the use of constants on a class level to keep the global namespace clean, hooks into the Zend Engine 2 and SPL when it makes sense, and __magic() functions in helpful cases (though there are no calls to __autoload() because of its scope). Each module is required to adhere to the “ZEnd Coding Standard” and is throughly tested with PHPUnit2 before it’s included (tests for these will be included as well).

And now, the moment you’ve all been waiting for – some code!

In this example, the use of their ZActiveRecord component is used to interact with a database:
[php]
nameFirst=”Andi”;
$person->nameLast=”Gutmans”;
$person->save();
?>
[/php]
It creates a new record for the class and performs an insert into the database for you. One key that they kept mentioning is the focus on “extreme simplicity” to get the job done, and this example shows that well. The ZActiveRecord functionality actually looks at your database for a table called “Person” and reads in the meta-data for it, grabbing column information and caching it for the object. Frm there, it’s just a matter of inserting data into the column values (nameFirst and nameLast) and saving it to the table. ZActiveRecord translates that information into a query and performs the insert all for you.

In this other example using the ZActiveRecord, a query is made for the matching values of nameFirst and nameLast and a row is returned. In the second example, a search is also made, but it returns all of the values found:
[php]
class Person extends ZActiveRecord {}
$zeev=Person::findFirst(
array(
‘nameFirst’=>’Zeev’,
‘nameLast’=>’Suraski’
)
);
//the result is then in $zeev

$people=Person::findAll(
array(‘nameFirst’=>’Daniel’)
);
//and now we can loop through the results just fine
foreach($people as $person){
echo $person->nameFirst.”n”;
}
[/php]

There were two other examples that they gave – the ZMail component and the ZSearch component – both with code examples. The ZSearch component is based on the Lucene search engine technology, but is written entirely in native PHP – no extra modules are required to get it working. It has a simplifed API to make the searching easy, and allows many different kind of query types including: phrase, proximity, and wildcard. Here’s an example of a query:
[php]
require_once(‘/path/to/ZSearch_class_file’);
$index=ZSearch::open(‘/tmp/index’);
$hits=$index->find(‘zend’);
foreach($hits as $hit){
echo $hit->getDocument()->getFieldValue(‘title’).”n”;
}
[/php]
The code above searches for the term “zend” in the index file that’s been created (ZSearch uses files to ensure the maximum amount of flexibility) and returns object results in $hits. One of the cooler things mentioned about the ZSearch module is the ability to look at multiple kinds of indexes with different data structures. They don’t even have to have the same field names for the script to discover matches for the terms.

From there, it was mostly a Q&A session with all sorts of questions about what the framework will be like, when it might be released and other various details. Here’s a list of the questions and their answers from Zend:

• How does Zend plan to make money off of the framework? – We don’t, we’re just contributing to the “PHP ecosystem” in a positive way
• Are there plans to compete on the compiled code level? – No, PHP, as a dynamic language performs very well, so we don’t see a need.
• Is there a release date set yet? – Not as of yet, but we are shooting for as soon as possible, possibly as soon as Q1.
• Can the framework be stripped down to keep the size of apps smaller? – Of course, it will be distributed in plan PHP files, but the real question is “why would you?”
• Will the framework be distributed as compiled files or standard PHP files? – It will be in stsandard, non-compiled PHP files
• How soon will things like documentation and use cases be made public? – We’re working heavily on the docs for the framework and will release them as soon as possible. We do hope, however, to have a more detailed site up within the next few weeks.
• Will it support Unicode in PHP6? – Most definitely
• What will the documentation be like? – The documentation relies heavily on phpDoc for reference, and higher-level documentation will be provided as well.
• How different are Zend Coding Standards from PEAR Coding Standards? – They are very similar, but with a few minor differences that are specific to the framework structure.
• Will all of the web services have a similar API? – With the differences in the structure of the services being different, there will not be much overlap in them.
• How will you push it out when the time comes to make a release? – “In every way possible” including the website, webcasts, etc.
• It seems that much of the framework is taken from Ruby on Rails, do you think you’re too late? – The only direct correlation between the Ruby stuff and our framework seems to be the ActiveRecord functionality. And, no, I don’t think we’re too late given the usage that PHP sees and its ever growing popularity.
• Will the framework be included in the test for the Zend Certification Exam? – As of yet, there are no plans to include it. There has been talk of separate testing, but nothing concrete yet.
• Will the framework scale well? – Definitely, it will fit well into the “increased performance” standard already set by the PHP language
• How will the framework fit into the CLI side of things? – Obviously, the controllers wouldn’t be of much use for a command-line app, but the majority of the components will work in both environments – the CLI side just won’t take as much advantage of the “glue” behind the scenes.

Well, there you have it – obviously, the answers from the above Q&A are paraphrased. I didn’t feel like writing out a transcript. I found the webcast to be quite enlightening and, especially with the inclusion of the sample code, has answered several of the questions that I had about things. There are still a few things that are a bit fuzzy to me about it – namely how one will become one of the “inner circle” of component developers down the line, but that’s the subject of a whole different blog post…