As I was trying out Zend Framework 1.6.2, certain things made me cringe:

• There’s a “Minimal” distribution, but it’s just as large as ever. Non-minimal I guess means with Dojo and unit tests. Forget the fact that I might never use Zend_Search_Lucene (Lucene search provider), Zend_Gdata (Googel Data API), or Zend_Service_Nirvanix (no clue).
• The “QuickStart” is ten-pages long and is a full-on tutorial on how to build a basic application. Not the “download this, put these files here, go to town” I was hoping for. Perhaps I’m being pedantic, forge on.
• On page 5, you create a bootstrap.php file which contains a bunch of application configuration details. All of these are pretty much stock and won’t change between applications. On page 7, you add a bunch of stuff to the bootstrap file so your application can do something esoteric like use view layouts. Also, there’s no explicit point telling you where to add the stuff. Hint: take the last “cleanup” step, remove that, and add in all the new code. This happens every time you modify the bootstrap. Yes, we do this more than once.
• When you’re creating your first layout, there’s nothing that tells you what file to put the example layout code in. I had to google that, find an unrelated tutorial, and guess-and-check my way back to a working sample app. (The unrelated Zend 1.5 tutorial said to use “default.phtml”, you need to use “layout.phtml” in whatever directory is in the bootstrap file.)
• On page 8 you update the bootstrap again, so your app has the privilege of reading a database config file.
• Whoops. On page 9 you update the bootstrap for the last time (in this tutorial). Because before when you set it up to read the database config file you didn’t set it up to actually connect to a database.
• Apparently, in the controllers you’re creating (on page 9), you have to tell the controller to fetch the controller’s model explicitly. Also your model has-a Zend_Db_Table object, but not just any Zend_DB_Table object – you create a subclass! So: Your “table model” explicitly gives the table name, and overrides the normal insert() and update() methods. Then you have a regular application Model that has this “table model” as an instance variable. In this “regular Application Model”, you have to explicitly write a save() function that takes a hash, rejects all of the entires whose keys don’t match a table column name, and then insert the array. You also write a fetchEntries() function that is just a wrapper around the much longer $this-getTable()-fetchAll(‘1′)-toArray(); call. Finally, you write a fetchEntry method that fetches an entry by ID. By far one of the most horrifying things I read, and this is the actual point where I gave up.
• Just for kicks, I checked out page 10 that shows you how to create a form the Zend Framework way. I was glad I stopped at the previous step: you actually define a subclass of Zend_Form that defines your form programmatically as an object, and your view automatically wires up based on the class name! So the only thing in your view is ?= $this-form. Not, y’know, HTML or anything. (Astute readers here will wonder, if we’re generating forms this way, how are they styled? Why, you just override the form’s decorator object! It is to gag.)

So, it turns out that steps 1-4 were pretty much things that a shell script could do for me.

After that I find myself writing code to do things like have my models save an array of data properly, or explicitly telling my “GuestbookController” that it should go out, require_once the “Guestbook” model (their autoloader only handles “library” items. “Application” items like models still need to be explicitly required!), and then instantiate a new Model_Guestbook().

And each time dorking with my bootstrap.php file and telling it to do things that the framework should really know how to do on its own.

And the form class!

Dear goodness, this is the way people choose do to things?