hellorobot.org

Graffiti, 
St. Petersburg, July 2006

Zend Frameworkincludes 4 posts.

Twitter Abandoning RoR?

If I had more time – or didn’t need sleep or food perhaps – I’d be interested in learning Ruby and Ruby on Rails, if only to see what all the fuss is about.

As I’ve begun experimenting more and more with PHP frameworks, one of my big worries would be that the frameworks enable quick development but only as a means of hedging bets: the site’s up and running fast but the problems are reserved for later: if a site succeeds, if it’s traffic increases immensely, then the framework could become the source, instead of the solution, to scalability problems. And how do you fix a problem that’s part of the system’s core? Re-do the core?

Rumors are that’s what’s happening at Twitter.

Continued Confusion in the Zend DB Class

I’m still questioning how I should best use the Zend Framework’s database model classes.

The data structure of the current application I’m building is not very complicated: there are 8 tables of between 2 and 11 fields each, and some of the tables are simple parent tables that define user types or status types.

To simplify, three of the tables that do the heaviest lifting do so in a hierarchy like a tree: a user table has a one-to-many relationship with a submissions table, which, in turn, has a one-to-many relationship with a recommendations table.

I extended the Zend_Db_Table_Abstract to model each table (as well described in the documentation). That was easy; I like that.

The Model in Zend’s MVC

I’ve begun building an application using the Zend Framework. I’ve incorporated a basic MVC structure, mapping some classes to the database tables. There’s a log-in form that I’ve created that authenticates via the database, and it works. I have some basic views created. Mostly it’s going well.

But the trouble is this: I don’t really know what to do with the model end of the framework.

Choosing a PHP Framework

The more I read up on the different frameworks the more reasons I find that people prefer one over another: ease of development; speed and scalability; plug-in architecture and add-on features; quality of documentation… All of it matters, but some, I think, much less: yes, it’s troublesome if a framework has poor documentation and is difficult to development in, but I think the length and slope of the learning curve is especially significant in conjunction with the results of mastery: a violin, for example, is one of the hardest musical instruments to learn, but once mastered, its potential far outstrips almost every other instrument.

Assuming a baseline of functionality – an object-relational mapping to the database, a reliable MVC structure, an authentication class, et cetera – and assuming a baseline of accessibility, where the documentation is detailed at least enough to allow mastery of a framework within a reasonable period of study, I think that frameworks should be evaluated on their maximum potential. A framework should be extensible, transparent, and professional.

Hellorobot.org is the development hub, blog, & portfolio site of Brian Leary. Who is Brian Leary?