Notes from the php|architect Zend Framework Webcast

UPDATE: if you’d like to listen to the actual webcast, head over here to the php|architect site and click on the first link.

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]
< ?php
class Person extends ZActiveRecord {}
$person=new Person();
$person->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…

25 comments

  1. Thanks for the recap! I enjoyed the Webcast very much and am looking forward to playing with the framework at the earliest opportunity. I think Zend is making all the right moves on this one and will help boost PHP’s commercial viability by a huge amount.

  2. Ack! I totally forgot about the webcast and missed it! (It’s written right there on a post-it in front of me, doh!) Thanks for your notes!

  3. Having created some ‘frameworks’ myself, im curious to know what problems they think they are solving with their new framework, as it obviously cant be a 1 true framework kind of approach, as most projects are different.

    Everything that comes out these days is getting compared to Rails, but to me it seems like everyone is missing the point on why Rails is cool in the first place. Yeah Ruby is a fun language, and scaffolding is a neat hard coded trick, but at the end of the day, people who have actually created projects in it fall in love with it for one reason, because it solves a problem for creating websites in a way that no other framework has been able to accomplish, it does it well and it doesnt really get in your way.

    There are also alot of other things that come with the framework that make it fun to work with: a web server, testing, and generators.

    The ideas that DHH came up with out of experience are good. Its great that the Ruby community has embraced it and is open to the sharing of ideas, alot of which a PHP framework can benefit from. If someone (or team) can come up with a way to organize and optimize an MVC style framework for PHP that runs super fast out of the box, is easy to get results quickly, that would be awesome. I see no benefit in make a function for function copy of Rails for php. Why not make something that just makes sense for PHP? Is that so wrong?

    I am familiar with some of the people working currently on the zend framework and do have some faith that they will turn out something cool. And hey, if I don’t like it, I can just use something else. ;)

  4. Nice recap – thanks for this as the webcast didn’t work for me! Which is a shame as I obviously missed a really informative presentation.

    It will be very interesting to see how this pans out. I don’t think this is going to be anything like Rails (and thank God PHP is nothing like Ruby) bar a few similar pieces of functionality. But from what I’ve read and heard so far, this is way removed from being a simple Rails clone and looks like being something quite unique. Roll on Q1.

  5. Pingback: Mitechie.com
  6. Looks good. The problem is that you’ll still be writing PHP, which is not as terse and as fast to code as Ruby. There are a lot more PHP hosts on the other hand…but not so much PHP5. I think that will change in the future, but there will be a lot more Ruby hosts too.

    The good thing about Rails is that it works. Other frameworks work in theory, with code-samples, but in practice they slow things down. I hope it will be possible to write code fast and clean. You can hack together a simple website very fast in vanilla PHP, but complicated websites are much harder. I hope this framework scales, not only for hits-per-second, but for programmers too.

  7. Pingback: Hannes og vefurinn
  8. It’s a good thing that Zend starts working on frameworks, but it seems that they are in a very early stage – as compared to other PHP frameworks like, say, symfony.

    Also, I don’t know what they mean about the “small kernel” thing, since they provide a lot of small add-ons (Zemail, Zsearch), so that doesn’t really make sense.

    But the implementation of ActiveRecord if cool. I just hope that it doesn’t stop at simple queries, they seem to insist very much on the fact that SQL will still be an important part of database requests.

    Wait and see…

  9. Pingback: Le blog d'Olivier
  10. This code is impossible with the current php5:

    class Person extends ZActiveRecord {}
    $people = Person::findAll();

    You have to instantiate a object every time no Object::findAll(), this is because you have to use get_class($this) to get the child classes name. This should really be fixed to return the proper class name, then you could do the Object::findAll(). So with the current versions of php5 you would be forced to do the follow:

    $person = new Person;
    $people = $person->findAll();

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>