One of my biggest criteria when I was looking at frameworks was how much each one wanted you to "drink the kool-aid." I'm not saying it's a bad thing to have co

One of my biggest criteria when I was looking at frameworks was how much each one wanted you to "drink the kool-aid." I'm not saying it's a bad thing to have conventions built into the framework to make developers' lives easier, but some frameworks really demand total commitment to their system. Since I was looking to slot the framework into a very large existing PHP codebase, I knew we couldn't immediately start doing everything "The _____ Way (tm)." Another criteria I used was to just browse through the quickstart and reference documentation and look at code examples. How complete were they? Did the accompanying description make clear what all options were available? Could I imagine adapting this code to work with our system? If the documentation was crappy, I was likely to give it a quick pass. Maybe a bit unfair, but a project that hasn't put in the time to make the docs shine has probably left some rough edges in other, less-obvious places (plus if we adopt it, I have to read that crappy documentation every week of my life). I ended up going with Zend, and haven't regretted that for a second. It's been quite easy to take the pieces of ZF that are useful to us and use them together or in isolation. The libraries are great, the documentation is (usually) wonderful and complete, and it all just works.