Propel: Parte Deux
November 4th, 2004After "Dusty's comment":http://revjim.net/comments/10165/#comment6042 in regard to "my Propel problems":http://revjim.net/item/10165/ (and I'm not sure why that didn't occur to me to try in the first place) I used the full path as my project directory. It worked, but still insisted on generating the classes into the global directory and, despite my attempts, I couldn't seem to find where to convince it otherwise. So, I had to run Phing as root (in my case) to have the proper permission to have the classes generated in that location. That was a bit annoying.
The next annoyance was *finding* the classes. Eventually I did though they were not at all where I expected them to be. Based on where they ended up, I'm convinced that there is either another episode of the ./ path problem creeping up or I just couldn't manage to find the proper XML file that stated where this stuff would go.
After finally finding the classes… well.. I was *shocked*. There's *a lot* of code in those classes. I understand BCs philosophy of "do as much as build time as possible" and I'm sure the size and complexity of the generated classes has a lot to do with that theory, but it almost seems ridiculous. After looking over the classes briefly it seems to me that a lot of this code could exist in core classes making the actual extended classes much smaller and simpler. However, this does shed quite a bit of light on *why* Propel is so dependant on Phing. It would almost be more trouble to generate those classes by hand than it would be to roll your own solution.
So, without moving a lot of that functionality into the core classes, it doesn't look like Propel is the right solution for me. I do, however, like Creole a lot. I've put in a few hours of code just seeing what it can do and it is very capable, quite easy to use, and fairly fast. I know the Creole site states that Jargon isn't quite complete, and I'd have to agree with that. It doesn't run under E_STRICT without Error and has a few namespace issues. On top of that, Record::save() and friends don't work nearly like I'd expect them to. It seems that I have to give Record::save() a Connection object as its first parameter. I don't understand why it wouldn't be able to save the connection from when it was originally instantiated. It also seems like it would make more sense to add two pieces of functionality. The first being a method that would allow the Value of the KeyDef to be specified and have the Record matching that value be returned. The second being a method that would use Creole's prepareStatement() functionality automatically for building where clauses instead of the current TableDataSet::where() functionality that just blindly allows a user to specify any where clause of their choosing without proper quoting or field handling. With this functionality already in Creole, why not use it?
I'm probably going to begin working on an alternative, more light-weight version of Propel with Creole as its backend that doesn't require Phing. Jargon is okay (with the above changes and corrections) but still isn't quite enough. Most importantly, I need TableDataSet to be able to return an object that extends Record, as opposed to a Record itself so that the objects being returned can have added functionality in them.
I'd like to thank Hans (the developer of Phing, Creole, and Propel) for the time and effort he's put into these Open Source products. It's nice to see competent developers (even if I don't agree with the philosophy behind the code) working with PHP5. It gives me hope that, someday, PHP5 might have as many tools as Java to enable developers to build clean, easy to maintain applications in a fraction of the time it takes today.


















