Innova Partners / Loosely Typed in Ohio

Software Zend Framework: WTF?

Posted by Jon Canady on November 4th, 2008

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?

permalink | 4 responses | share this

Software Database Models I Have Known And Endured

Posted by Eddie Bowen on October 17th, 2008

One thing you might have noticed that we do is SQL. We do a lot of SQL, so you’d think we would have figured out the best way of hooking up applications to databases.

To an extent, we have become so familiar with the requirements of database-driven development that we have come to accept the tools that we have as being adequate. Even ODBC.

Obviously we’ve long ago moved past PHP functions like mysql_fetch_row. We expect things like sanitizing and escaping, multiple vendor support, query abstraction, and so on. We look back fondly on the clumsy simplicity (and scope for injection) of things like this:

PHP

mysql_query( "SELECT * FROM T_Shirt WHERE color = '{$favorite_color}'" );

Nowadays we’re more likely to fetch records through a framework API, such as this use of Zend Framework’s Zend_Db:

PHP / Zend Framework

$db = Page::getDb();
$select = $db->select();
$select->from( 'T_Shirts' );
$select->where( 'color = ?', $favorite_color );

return $db->fetchAll( $select );

Because the query is broken down into a set of calls we can pass the select object around before we do the fetch. This is surprisingly handy.

But what else is out there that might be better than what we’re doing now? What would be the next step, the thing that would make Zend_Db look like mysql_query?

permalink | 2 responses | share this

Software Eclipse FTW!

Posted by Eddie Bowen on August 7th, 2008

Eclipse: when it rocks it rocks, but when it goes pear-shaped, it really does go pear-shaped.

permalink | no responses | share this

Software Capistrano? In my PHP? It’s more likely than you think!

Posted by Jon Canady on April 25th, 2008

For most of Innova’s applications, we’ve got two environments: staging and production. So it was an easy thing to just hit the proper server and do an SVN operation to push out new code.

With our new project, IMEBase we have a little more complexity in mind: we’ve got multiple testing and multiple production environments. Doing all of our SVN stuff manually would be error-prone and boring as hell.

Enter Capistrano.

permalink | no responses | share this

Software Deploying via SVN

Posted by Kent Broestl on April 8th, 2008

So… How long does it take for you to update your WordPress.org sites?

A while back we decided to switch all our WordPress installs to svn, since the good people over at WordPress release their software via svn tags.

So now, the process of updating a WordPress site consists of this: backup the database, disable all the plugins then do the svn switch, which looks like this:

http://svn.automattic.com/wordpress/tags/2.5

hit the wp-admin page again (which will update the database… You remembered to back up, right?) then re-enable the plugins. And you’re pretty much done.

With fast connections, the whole process only takes about 5 minutes per site. You can’t scp faster.

Obviously, do a few tests on your own, and get the process under your fingers, but this becomes such a time saver.

If you’re not using svn (or a similar technology… Personally, I like git, and here’s one reason why…), you’re asking for trouble. See problem #36 here.

Now if only more of the tools that we all depend on would do svn tagging… (of course, we already know that Zend does… but we need more!)

permalink | no responses | share this