Recently, I finished my first production-quality Zend Framework application. It was a new website that made use of an old backend that powers another application I wrote using a custom framework. I wanted to use Zend Framework to practice on it, and to learn things I hadn’t yet learned since I had yet to put an application into production; however, I didn’t have any desire to rewrite my model, which was done in Propel.
Propel has two things going for it already: the first is that Propel includes its own autoloader, meaning that I didn’t have to try and force Propel into Zend Framework’s file system structure. The second is that Propel is designed to let you put it’s files anywhere you want with ease, so long as you update your include path properly. This made the process significantly easier than I had thought it would be.
Monday, March 22nd, 2010 @ 7:00 am |
Comment (3) |
Categories: Zend Framework, Technology
Tags: Propel, model, MVC, Zend Framework
Anyone who knows me knows that when I talk about the model, I’m usually talking about Propel. I’ve liked Propel ever since I started working with it in the middle of last year; I personally find it easier and more fun to use than Doctrine or other ORMs available today. I was excited to see recently that Propel’s development team had released Propel 1.5 as a beta, with a launch of the new features to come soon.
There are a couple new features in Propel 1.5 that I think are going to be pretty awesome additions. Here are my two favorites:
Tuesday, February 23rd, 2010 @ 10:58 pm |
Comment (3) |
Categories: Technology, General PHP
Tags: Propel, model, MVC, beta release
This entry is part of an ongoing series involving the review of a code sample and it’s refactoring. For the original code sample, see here.
Editor’s Note: The response of the community to this series has been great, and I’ve been given a large number of suggestions. I’ve incorporated some of those suggestions into the code and into this article. Thanks to Jeff Carouth, Greg Beaver and Daniel O’Connor for their help and suggestions.
This entry will focus on our use of the database, and specifically on the already_tweeted() method. This method has a number of problems, and while we’re focusing on the implementation of the database, it’s important to note that we will also need to address some of the logic (which will be the next part of the series).
In our last entry, we focused on abstracting the HTTP request out to a seperate class. Lots of people wrote comments with suggestions of HTTP handlers, including pecl_http, the PEAR HTTP class, HTTP_Request2 and the PEAR Log class for logging. These are all great suggestions, and all will help abstract out the class without causing us to have to write our own implementation of common problems (the Not Invented Here (N-I-H) syndrome).
In focusing on the already_tweeted method, one thing becomes immediately apparent: it is private. This suggestion, provided by Greg Beaver relates to our first discussion of coding standards and we will change the class to a protected class for extendability later on.
(more…)
Monday, August 31st, 2009 @ 6:30 am |
Comment (2) |
Categories: Debugging, Best Practices, System Architecture
Tags: OOP, PHP 5, Propel