What Makes a QuickStart Great Clarity Good narrative, with sections that may be skipped over if desired Visual Guides (screenshots, for example) A little humor Great examples with downloadable code . . .among many other things. Look at your personal favorites for inspiration!

Zend Framework QuickStart

Welcome

Welcome to the wonderful world of Zend Framework! As you look around, you'll notice lots of useful components to use in your applications, especially if they happen to be web applications. That's because Zend Framework is a small part of something much larger: the universe of web development. This universe holds all kinds of ideas, technologies, and standards. Zend Framework picks the best of all these ideas, technologies, and standards, and presents them to you in one elegant package. So you might think of Zend Framework as the best of all worlds. The 'best of all worlds' has gone by many names over the course of human history- paradise, Eden, Shangri-la, nirvana, and so forth.
Let's review what we've learnt so far:

• Zend Framework is like paradise, Eden, Shangri-la, and nirvana all rolled in to one for web development.

Not bad for the first paragraph, huh?

Hello World

Now it's time for you to introduce yourself to the world of Zend Framework. If only there were some kind of simple application you could write to introduce yourself to a world. . .

OK, enough screwing around. It's time to get down to serious business with a Hello World application. Now pay close attention and follow each step down to the letter:

1) Make sure your web server is running PHP 5.1.4 or greater. If you are in a hosting environment that is running a earlier version of PHP, switch hosts.
2) Create a file in the 'document root' directory of your web server. Let's just call it 'index.php', even though it has nothing at all to do with an index of any sort. What a wacky bunch of developers we are!
3) Insert the following in to this file:

4) Type your server name in your web browser. Make sure you replace 'your server name' with your server name.

OK, that should do it. If you experience any problems up to this point, make sure you create an issue in our issue tracker. I'm kidding, of course- you should only create issues that we actually care about in our issue tracker.
"But wait," I can hear you thinking now, "that's just a PHP application!" Time for the first revelation, Daniel-san: a Zend Framework application is a PHP application. I'll just wait for a second to let that sink in. . .
All right, time to drop the next bomb: there is nothing in particular that makes a Zend Framework application a Zend Framework application. Sure, use of one or more Zend Framework components is a strong indicator, but ZF apps come in all shapes and sizes. There is no predefined structure, no obligatory design patterns, and no required components. That's right! You can take or leave any ZF component and generally use it as you wish. We like to call this our 'use-at-will architecture'. Other's might call it 'common sense'. You'll see this philosophy permeating the framework. We have a strong belief that you understand your application's requirements better than we do, so we'll just stand quietly over here in the corner whispering about best practices and waiting for you to decide you need one of our components.

The Component Lineup

"I'm sold!," you shout. "I want to use all of the ZF components in my next application!" Slow down there, Speedy Gonzales. Zend Framework is a complex framework that can do many things, and the best way to get to know it is one step at a time or, in this case, one component at a time.
And besides, you haven't even set up a basic ZF project yet. Let's get that out of the way first. . .

Project Structure

One of the first things that people notice about Zend Framework is that it doesn't have a rigid project structure. A ZF project can be as simple as one PHP file, and as complex as the Special Theory of Relativity. With very few exceptions the locations and names of files are up to you.
Believe it or not, this is one of the most criticized features of Zend Framework. In a development environment dominated by Ruby on Rails and the clones, developers have come to the conclusion that they shouldn't have to conceive of, create, or even care about their project structure. This seems to work very well for many projects, but we believe that no one project structure can serve everyone equally well, especially with all those pesky hosting environments and special application requirements out there. This is another example of Zend Framework prioritizing practicality over clean, conventional, and oversimplified elegance.
All right, I'll be the first to admit that's a total cop out. There is no reason you shouldn't have your baked confection and eat it, too. Here's a little secret- we're actually working on a tool that will give you all the advantages of a convention-based project structure, while not penalizing those who audaciously prefer their own structure. But for now, we'll just have to bite the bullet and do it ourselves.
First we'll need some entry point in the document root of your web server. That 'index.php' file we already created should work nicely.
For all kinds of security reasons, we want to keep as little code and configuration as possible under our document root. So let's create a folder next to the document root folder called 'application'. That should be as good a place as any to keep our application code. Of course, you'll need to use a bit of Zend Framework code that should also be kept in secure place. A folder called 'library' next to our 'application' and 'public' folder should do the trick. You'll want to copy the 'Zend' folder out of the 'library' folder of your Zend Framework package. You have downloaded the Zend Framework package, haven't you? If not, you can download it [http://framework.zend.com/download ]. Pick any version as long as it's the 1.5 release or later.
Assuming your document root points to a directory called 'public' under a directory called 'QuickStart', your project should now look like this:

What's this you say? Your document root isn't in a folder called 'public' under a folder called 'QuickStart'? Weird. OK, you can always change the document root for your web server to follow along at home. Just take a look at your web server's QuickStart. It's not as if I can't tell you how to do this for the 2 biggies that the vast majority of you are probably running; it's that QuickStarts have to help each other out once in a while if we all want to get ahead in this world. Once you're done with that QuickStart, make sure that both 'public' and 'application' are readable by the user under which your server is running. All the folders and files under these two folders should also be readable by the web server user. The QuickStart should have covered how to do all this. If not, find another QuickStart.
Now, in the spirit of putting as little code as possible in the document root, replace the contents of 'index.php' with the following:

There's just one more thing to do before we leave this folder. Gosh, it would be super-duper if we could structure the URL's for our application however we want. Just imagine the terror we could strike in to the hearts of users everywhere with a URL like 'http://www.example.com/spam/signup'. Well, we can do just this using Zend Framework, but we have to give it a little help first. We'll have to somehow 'rewrite' all the dynamic content to some well known entry point for ZF. Since index.php is already there, let's use that. If you're using Apache, you can drop a '.htaccess' file next to the 'index.php' file with the following contents:

Of course you need to have mod_rewrite enabled and Apache configured to apply these rules for this directory, but I hardly think we need to go in to that here. And don't even bring up IIS. I'm sure this stuff is documented somewhere.
Now let's go to where the action is: the 'application' directory. Since we took the liberty of requiring a file called 'bootstrap.php' above, let's go ahead and create that file now with the following content:

All right! Time to test your ZF application. You should see the text 'Hello World' in your browser. When you're done marvelling at the sheer power that ZF has already brought to this application, we can move on. BTW, if you're curious about why this file is called 'bootstrap.php', then don't be. We'll get to that soon enough.

Zend_View and Zend_Controller

The components Zend_View and Zend_Controller go together like two peas in a pod. Or, slightly less metaphorically, like the letters 'V' and 'C' in the acronym 'MVC'. Indeed, Zend_View provides the view part of the MVC pattern as implemented in Zend Framework, whereas Zend_Controller provides the controller. Actually, Zend_Controller provides not just one, but two kinds of controllers: the front controller and the action controller. The front controller is like the conductor of the symfony that is your application; it routes requests from one controller to the next and makes sure everything comes together for the response. The action controller is actually an abstract class that we'll have to extend with one or more classes to implement our application's unique routing requirements. When you hear people talking about 'controllers' in MVC-based web applications, they are usually talking about action controllers. Typically the controller and view code is inseparable in frameworks implementing MVC; Zend Framework provides a little more flexibility here in that you can use Zend_View and Zend_Controller separately. In fact, you don't have to use any MVC components at all in ZF! But for the purposes of this QuickStart, we'll go along with the crowd and build an MVC application.
So where is Zend_Model? You wouldn't believe how often we get asked that. ZF'ers see models made up of pretty much every part of your application that isn't a view or a controller. That is, the models implement all the data storage and business logic of your application, while the views and controllers concern themselves with showing stuff to the user and collecting the user's input. As such, there isn't much of a formalism to code up for a model that would be of any use. Essentially, we leave the structure of this extremely application-specific part of the application up to the developer.
Now how do we get this whole process kicked off? Well, open your 'bootstrap.php' file and replace its contents with the following:

Holy action controllers, Batman! Sorry, I probably should have warned you before barfing all that code at you. But no worries, it's all very straightforward. First we alter our 'include_path' so that the Zend Framework code is thrown in there along with everything else you have in your 'include_path'. Of course, you can always set this in your 'php.ini' if you'd prefer. Next we take advantage of our freshly modified 'include_path' to include the Zend_Loader class. I suppose this is as good a time as any to mention that ZF uses the [http://pear.php.net/manual/en/standards.php ] to name its classes (along with all of the other PEAR coding standards). This just means that ZF's classes are organized in directories to form 'packages' or 'namespaces', and the class names include all of the directories that contain the class separated by underscores. So the 'Zend/Controller/Front.php' file contains the 'Zend_Controller_Front' class. We include 'Zend/Loader.php' first because it knows how to include the right file given just the class name. From here on out we can just use class names with Zend_Loader, or file names with 'include'. It's up to you. Really.
The next thing you'll notice is this Zend_Controller_Front class. This is what those wacky ZF developers call the class that implements the front controller. Since the front controller is responsible for routing the request and putting the response together, you shouldn't be too surprised that we very quickly let Zend_Controller_Front drive by calling the 'run()' class method with the directory that contains our action controllers.
Now, back to the matter of the name of this 'bootstrap.php' file. As you can see, we need to do a few things to get the application ready to handle each request. In this example, we're altering the include path and loading the Zend_Loader and Zend_Controller_Front files, but in a typical application you'll be doing a lot more before handing the keys over to Zend_Controller_Front. This code could be consider 'bootstrap' code in that it must be performed before the application can do its job. Hence, the name.
There's only one problem with this whole scenario- we don't have any action controllers for the front controller to service the request with! Let's add a 'controllers' folder to our 'application' folder. And while we're add it, let's throw a 'views' folder in there, too. We'll create an 'IndexController.php' file in the 'controllers' folder and create one action controller in a file called 'IndexController.php' with these contents:

All right, now we're cooking! We just defined a class that extends the Zend_Controller_Action abstract to create our first action controller, just like we said we would. We've called it IndexController (we'd normally use PEAR conventions as a best practice, but we haven't 'packaged' this class in any folders). And looky there- we have one method called 'indexAction' that does exactly nothing. As you'll see later, however, 'indexAction()' is doing something by simply existing; it is one action method on our action controller. Now you know why they're called action controllers: they are controllers that contain one or more actions! Note the naming convention here with camelCase and the 'Action' suffix. By default the request router will look for the requested action method by its camelCased named with 'Action' appended to it. If it were named 'indexActionJackson' the router wouldn't be able to find it. Respect due, Carl Weathers.
Right about now you're probably wondering when we'll actually see some HTML in this web application. In the MVC pattern, views typically contain HTML and correspond one-to-one with an action on a controller. Keep in mind that this is not always the case- views can output pretty anything you can imagine (and implement) and some actions have no corresponding views while some views have no corresponding actions. For now, let's stick with this whole one-to-one correspondence thing.
Create

The Environment

It's very important to understand from the outset that Zend Framework is very much a product of its environment. In this case, the environment is made up of all kinds of things: the web development community, the PHP runtime, the servers that Zend Framework is used on, Zend Framework's own community, etc. As you can see, a lot of very different factors have influenced the design and development of ZF. But every one of these things is a tiny part that add up to one gigantic nut: the web application universe. And it is exactly this nut that PHP and Zend Framework were created to crack. Like any product of its environment, you can take Zend Framework out of the web application universe, but you can't take the web application universe out of Zend Framework.
Now Zend Framework is hardly the first body of code to tackle the many problems that the web application universe has to throw at it. There have been many designs and technologies that have taken on these problems over the last decade or so. Indeed the path to the great frameworks we have today is littered with ideas and technologies that boast elegant designs and clever techniques, but which simply haven't proven as useful as other ideas and technologies in practice. Zend Framework itself aims to be above all a practical framework, culling some of the best ideas out of our cumulative body of web development knowledge. Some of these ideas you have undoubtedly heard about: MVC, DRY, CoC, IoC, ETC. I suppose one of the lessons to be learned here is that all cool ideas must have cool acronyms. Some of the technologies you've also heard about: Java, J2EE, .Net, PHP, Ruby on Rails, Django. Believe me, the list goes on. As a first and foremost practical technology, Zend Framework distills some of the best ideas from these techniques and technologies to bring all these best practices to you, the web application developer.

The Learning Curve

That said, Zend Framework gets a bit picky about which best practices it implements. For example, the designers of ZF have not prioritized the development of project generators or scaffolding because they believe that, while these practices are useful, they are not going to bring as much value to everyday development as components such as Zend_Controller, Zend_View, Zend_Form, and Zend_Db. This turns out to be a very bold statement in the current web development environment. ZF will not build an application for you with a few simple commands- that's why you're ready this, right? On the other hand, when your requirements dictate an unconventional project structure, Zend Framework will keep up with you. So the first hour of Zend Framework development is about getting to know Zend Framework itself, not necessarily a few ZF commands. This makes for a somewhat higher learning curve than some other technologies, but at the end we hope you have some idea of the universe of problems that ZF can solve.

This is the second section

This is the content of the second section.