Hi,

People ask me from time to time, what PHP framework is the best one to learn?

Well, I always look at technology choices with two things in mind:

1. How capable is the technology?
2. How accepted is the technology?

If you look around, it becomes pretty clear, that if you want to learn an effective web application framework, you want to learn the Zend Framework – indeed, the trend is with Zend.

Zend framework being used by companies large and small

I know from first-nerd experience that the Zend Framework is being widely adopted. Just recently for example, Intuit and the BBC have implemented new web apps that are Zend Framework based.

… I know because my good buddy Jon Lebensold of Zendcasts helped build one of them.

There are plenty of other examples out there I’m sure … and I am confident that the trend will continue towards the adoption of the Zend Framework. With the PHP company (Zend) and IBM behind it … it doesn’t take a brain surgeon to figure that one out.

Thanks for reading,

Stefan Mischook
www.killerphp.com

Hi,

I’ve been busy with things and so not too many updates lately. Not to worry thought, we have a brand new course and lots of free videos coming out soon on advanced MySQL.

In the following podcast (it was a video but I changed my mind …), I talk about the pragmatism of the Zend Framework dudes.

MP3: zendframework-and-doctrine

Short and sweet.

Stefan Mischook
www.killerphp.com

My good buddy and right-hand-nerd, Jon is being flown down to do a live webinar for the Zend geeks at Intuit. It seems the accounting giant has recognized Jon’s ability to take the complex and make it seem simple.

Just in case you don’t know, Jon is the author of our crazy cool shopping cart tutorial and our new series on advanced PHP.

… Jon is starting to realize that my choice to go with the Zend Framework a few years ago made sense. Actually, it made dollars and cents!

OK, bad nerd humor … I know. I’m just low on material that isn’t profanity laced.

If you want to know WHY, after looking at all the other PHP frameworks out there, that I thought the Zend Framework was the best choice long term (even back when Zend was still in Beta) .. you’re going to have to ask!

Anyway here is the official announcement:

Jon Lebensold, author of the popular PHP Shopping Cart and founder of Zendcasts.com will be writing a Google Wave Gadget in Boston at Intuit’s East coast office. Intuit is setting up a live webinar which you can attend by registering on the Zendcasts website.

Zendcasts.com began this year with the hope of assisting intermediate PHP developers further their Zend Framework skills. If you’re a PHP developer interested in building apps on Google Wave or want to watch someone build an AJAX application with web services like Google Wave and Intuit’s QuickBase, this free webinar will be worth spending a lunch hour at your desk.

The webinar takes place Wednesday, November 18 at 12:00 (noon) Eastern Standard Time (GMT -05:00).Register online now.

Here’s the banner:

Just in case you are not familiar with Quickbase … just click on the link.

That’s it for today. But coming soon, I will have some pretty big news … actually, the biggest thing to come to killerphp.com since we ordered that huge pizza! Ok, even bigger than that!!

Stefan Mischook
www.killerphp.com

Hi,

In response to my a recent podcast where I recommended that PHP programmers learn the Zend Framework, I was asked why I choose Zend, rather than other PHP frameworks.

The video:

Some notes:

Just in case you can’t stand listening me bather about this in my videocast, here are the bullet points:

• Choose an MVC framework.
• Choose a framework that is flexible.
• Choose a framework that has a strong community backing it.

The details to the above points are of course found in the videocast.

HD videos are still a work in progress:

I know the new video presentations need some polish – they are a work in progress. So I appreciate your patience with me as I work out my kinks.

Anyway, I hope you find them useful.

Stefan Mischook

www.killerphp.com

I’ve released our second video (part 2 of 2) on setting up an MVC structure with the Zend Framework.

This Zend Framework video is from our resident Zend-nerd: Jon Lebensold.

Again, let us know what you think and should you have any suggestions or request, please feel free to comment.

Running time: 19+ minutes
Part 2 of 2

Thanks,

Stefan Mischook

www.killerphp.com
www.killersites.com

I just released a new video on setting up an MVC structure with the Zend Framework. This video is a little more basic than the previous Zend videos … I had to twist Jon’s arm a little.

Anyway, let us know what you think and should you have any suggestions or request, please feel free to comment.

Running time: 12+ minutes
Part 1 of 2.

Thanks,

Stefan Mischook

www.killerphp.com
www.killersites.com

Now that the Zend Framework is ready for ‘prime time’, I’ve been considering the Pear framework with regards to how it now fits in the PHP world.

NOTE:

Several picky nerds have pointed out that PEAR is not a framework – check out the comments below. OK, I would agree, technically speaking, PEAR is not a framework. That said, this is what the PEAR people say on the home page of their web site:

‘PEAR is a framework and distribution system for reusable PHP components. You can find help using PEAR packages in the online manual and the FAQ.’

Anyway, that is an argument of semantics and nerd-details … not the point of my article.

… Back to my article:

Both Zend and Pear are frameworks but how are they different?

I would say that the Zend Framework attempts to create a comprehensive whole – a consistent set of components that are designed to work together in a unified manner.

… That is one of the reasons for a framework in the first place.

Though unified, one of the cool things about the Zend Framework is that you can just pick and choose what components you want to use – you don’t have to buy the whole cake to take advantage of all that juicy object oriented PHP code.

About PEAR:

With the Pear framework, it is more of a hodgepodge/motley of assorted components. Pear is widely used (and useful) but it does cross over (in terms of functionality) with what we have in the Zend Framework. So the question that comes to my mind is:

Do we still use Pear, if we have the Zend Framework?

The simple answer is found in the version of PHP you are using:

If you are using PHP 4, you will have to use PEAR since the Zend Framework depends on PHP 5. Remember that PEAR does predate the Zend Framework.

And on the flip side, if you are using PHP 5, you might as well favor the Zend Framework since it is a comprehensive unified framework.

-

While considering this question (PEAR vs. ZEND Framework) I struck up a conversation with Jonathan about this … I thought it was worth including here:

Hi,

I was wondering what you thought about Pear given that Zend is out?

… Is there cross over or does Zend leverage Pear?

Thanks,

Stefan

Jonathan Lebensold wrote:

From what I’ve seen there’s no dependency with Pear in Zend. Although Zend appears to be a higher-level functional replacement for Pear. (Pear kinda sat between what you would expect php to provide you in extensions and what would facilitate a developer in writing applications. That distinction is now made through extensions / PECL (C libraries) and Zend)

J.

From what I can see, if you are using PHP5, Pear is no longer needed because of Zend – would you agree?

Stefan

Jonathan Lebensold wrote:

I think that pear will be deprecated since it was unreliably deployed on webhosts (which led people to dumping instances of the whole PEAR framework into their applications.. mind you that’s what people are doing with ZEND).

I would say that PEAR is on the downward slope, but a lot of legacy code depended on it (especially from PHP4 era). newer applications should look towards independent classes (like the ones at phpclasses.org) or solutions provided in frameworks (like smarty / zend / cake / etc…)

j

Conclusion:

We’ve developed a couple of Web 2.0 applications with beta versions of the Zend Framework and I think we made a good choice:

… Even with that early version of the framework, we found it to be very useful and worth implementing.

Another bright spot, was that we got new developers productive with the Zend Framework rather quickly. A nice change from what I had to deal with during my Java days! Did I say Web Objects sucks?

Anyway, I’m excited to explore the latest releases of the Zend Framework and to write more about it as time permits.

Thanks for reading,

Stefan Mischook

I just launched a new section on Killerphp.com on the Zend Framework.

I figured it only made sense, given that we’ve built two live web applications based on it:

Video sharing site: www.idea22.com
Web template sharing site: www.webshapes.org

-

For those of you who are not familar with the Zend Framework:

The Zend Framework is a web application framework designed to make building complex PHP based web applications easier.

The Zend Framework contains a series of components (built using PHP 5) that manages many common task in web application development:

* Zend_Form: to make form handling/processing easier.
* Zend_Mail: makes email functionality trivial to create in PHP.
* Zend_Db_Adapter: to connect to databases.
* Zend_Pdf: allows you to easily create and edit PDF documents.

… And this is just a small sampling.

-

There is a lot more in the works in terms of our videos and articles.

Thanks,

Stefan Mischook

www.killerphp.com
www.killersites.com

Whether you’re developing an ASP.NET application, working with rails or dealing with a templating engine like Smarty, the idea of partial templates is not foreign. Partial templates allow developers and designers to work with panels or sub-groupings of content that need to be dynamic.

With a proper AJAX framework in place, these controls can be written in a way that they can be updated in whichever Controller they eventually reside. This kind of flexibility can allow you the flexibility of using certain signature controls for multiple parts of an application.

For example, you could develop an AJAX comment box that would write comments for articles and blog posts but would hit different database tables based on it’s constructer. The rest of the control would remain the same, resulting in a more consistent look and feel for your users.

View Helpers are not partials in the Ruby on Rails sense since they’re is view logic associated with them and they don’t explicitly have .phtml files. View Helpers also aren’t like wordpress templates, with content broken up into different parts (a good example of this kind of compositional design will be coming in the Zend_Layout package to be released soon).

View Helpers seem to resemble the user control concept of in .NET, where a panel can be dropped into any form, with its codebehind managing any events or user-control specific display code.

In summary, View Helpers are great for encapsulating forms, grids and other functionality that could eventually be bound to a different data source or even be pushed back to the user through a simple AJAX call.

According to the samples provided in the Zend documentation, View Helpers seem to mix presentation with logic. My assumption is this was intended to limit the creation of Zend_View objects since Zend_View can load View Helpers dynamically.

The View Helper sample provided in the zend documentation looks like this:

While this works for simple output, where a View Helper would be interacting with the calling object (which is typically the Zend_View), this approach doesn’t lend itself to doing rich partial templating.

As long as you keep the Helpers in one phtml file, you could add a “helpers” folder to your document tree and render the View Helper like any other view. The advantage of this is that factoring out part of your template into an AJAX control becomes really trivial. Furthermore, your display and view logic are separated, and lastly, you could even test the View Helper (including its behaviour) without a particular controller action in mind.

These javascript samples could be written more elegantly by loading the javascript through a referenced javascript file file that is tailored to a particular part of an application.

The actual index.phtml page could look something like this:

Notice how I’ve called MyPost twice? each one of these view helpers will have its own javascript configuration and will fire independently of it’s predecessor, thanks to View Helpers being able to call their inheritor to see how many times they’ve been invoked on a page.

The actual helpers/MyPost.phtml page would then look like this:

Notice that the View Helper itself is using another View Helper (formSubmit) to simplify the submit button on the actual form. We could easily extend this example with lookups that would dictate the visibility of certain portions of the View Helper. This way, the View Helper is responsible for rendering logic and it can be given a set of data to render the View by, or rather, it can “call out” in the actual Zend_View_Helper_MyPost class.

MyPost.php (the code-behind for the View Helper):

This is an example of a form that could be dynamically posted from any page in your application.

Notice how the javascript uses the “formId” (which could be derived through using the same method as $this_count++ in the previous example) to maintain uniqueness. This enables the creation of multiple instances of the View Helper on the page, all bound to their own javascript event listeners or custom javascript.

Using prototype, you can submit directly to that particular version of the ajaxMethod or even post the View Helpers’ form to a Controller that supports Ajax Postbacks. Luckily, proposals like Zend_Controller_Action_Helper_AjaxContext intend to facilitate this process of managing how a view is rendered from a controller. In this particular example, I’ve created a custom AjaxController for my application that looks like this:

The custom View Helper will post to MyPostAction where the standard Zend_Controller methods can be used to collect the postback and return an XML result. This way, you can easily migrate existing postback code into an AJAX-enabled view-helper. MyPostAction has been configured to return xml instead of a regular phtml template. In order for this to work, you need to disable default rendering in the init() function of the AjaxController:

The same technique can be applied to a JSON formatted response, where prototype (or any other javascript framework one of your choice) could be used to pick up the response and create a javascript “object” that’s ready for rendering.

As part of a series of articles about the Zend Framework and MVC, I’d like to take some time and cover Zend_View (the ‘V’ in that MVC triad).

Within the Zend Framework architecture and documentation, Zend_View is often coupled with the Zend_Controller as a means of providing a templating engine that encourages smart defaults over explicit programming.

For example, if I have a Controller named ‘AccountsController’ with an action (AKA a method that ends in ‘Action’ inside the AccountsController) called “new”, this would be mapped to the url “mydomain.com/Accounts/new”.

After running whatever is found inside AccountsConroller::newAction(), the Zend_Controller would be clever enough to dig out of my application/views/scripts folder, the Accounts/new.phtml file as a template for the action in question.

This sounds great at first, however you’ll find yourself adding:

< ? php include 'scripts/header.php'; ?>

… to the top and:

< ? php include 'scripts/footer.php'; ?>

… to the bottom of every phtml file! This breaks the DRY principle (Don’t Repeat Yourself!) which leads us to…

Creating a Standard Layout for all Zend_Views Loaded by Zend_Controller

The default behaviour of Zend_Controller is actually handled by the Zend_Controller_Front class, which then routes and loads the appropriate Controller in your application. In order to inject a custom template, we need to do three things:

1- Write a Layout Plugin
2- Create our beautiful layout
3- Register the plugin

The LayoutPlugin is a piece of cake, especially since I’ve written a class that can be implemented in any project:

/*
* Handles the header / footer by capturing the preDispatch and postDispatch of the
* response object
*
*/
class LayoutPlugin extends Zend_Controller_Plugin_Abstract
{
private $view;
function __construct()
{
$this->view = new Zend_View();
$this->view->setScriptPath(’../application/views/scripts’);
}

/*
* Run at the beginning of the controller’s response object initialization
*/
public function preDispatch( Zend_Controller_Request_Abstract $request )
{
$this->getResponse()->prepend(’header’,$this->view->render(’header.phtml’,null,true));
}
/*
* Run at the end of the controller’s response object initialization
*/
public function postDispatch( Zend_Controller_Request_Abstract $request )
{
$this->getResponse()->append(’footer’, $this->view->render(’footer.phtml’,null,true));
}

}

The interesting parts of this class are setScriptPath() , prepend() and append(). Essentially, the Zend Plugin architecture is expecting preDispatch and postDispatch to be available in any plugin that’s injected into the Front_Controller.

What we’re basically doing is telling Zend_Front_Controller to prepend ‘header.phtml’ and append ‘footer.phtml’ to all of our pages. We could get fancier by pulling a variable from our registry that would affect which header and footer is loaded (see my previous blog post for a sample of how to use Zend_Registry).

Step 2 is adding ‘header.phtml’ and ‘footer.phtml’ to your application/views/scripts/ folder with their respective headers and footers. Personally, I like to start my websites either with an open source template from LayoutGala or Webshapes so that I have a good structural starting point for my application.

Step 3 is simply registering the component. In your index.php, assuming you’ve setup Zend_Loader to register classes automatically, one line of code needs to be added after Zend_Front_Controller is declared:

$controller = Zend_Controller_Front::getInstance();
// add the following to register our newly-created layout plugin.
$controller->registerPlugin(new LayoutPlugin());
$controller->dispatch();

In my next post, I’ll cover using Zend_View without Zend_Controller. This will lead up to creating custom View Helpers that can then be loaded dynamically through your PHP AJAX framework of choice!