hellorobot.org

Graffiti, 
St. Petersburg, July 2006

OOPincludes 4 posts.

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.

A Better Understanding of the MVC Pattern

“MVC helps to reduce the complexity in architectural design, and to increase flexibility and reuse.” In a web application, the model is the most static element across time; the data behind a website may change but the shape of the data, the organization of the data, if well constructed, is fairly stable. The physical appearance and degree of interactivity of the site’s actual web pages – this will change the most: adapting to new delivery formats (iPhone, text readers, etc.) as well as adjusting regularly to design trends and new technologies (consider the way AJAX changed the possibilities of front-end development).

Creating a consistent, encapsulated layer around the data, one that’s easy to maintain, is good. It’s extending the lifetime of that data structure, creating the ability to apply it to multiple view types and demands. It makes sense then that the model is blind to the view. And if the controller were always the intermediary between the two, the controller would be too tightly coupled to each: any real change to the view would require one to the controller as well. That’s where my first interpretation of MVC went awry. What was the point of having three components? That’s what didn’t make sense. The controller was basically an extension of the view.

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.

Specificity Helps Put the Cascade in CSS

Why oh why, is that element displayed like that when I cleary wrote the CSS to display it like this?! Mostly, in these situations, the browser’s got it right, and I’m the bumbling doofus. Too many times, my error lies in a mishandling of CSS specificity.

I love that CSS allows for multiple class names, and I assign them often. It’s a great way to mark alternating rows in a table-like structure, for instance, or to mark up panels on a page that are exactly alike but for one attribute. But since two class definitions have equal specificity, the exact element reference and location within the CSS determines the output.

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