Propel: a non-review
November 2nd, 2004Wanting to shave a few hours off of coding time and avoid all the stumbling blocks that are certain to occur when dealing with writing flexible objects for use in multiple projects, I decided that I'd try to find an existing package to handle object persistance (aka. DataObjects) in PHP. The following is an account of one such attempt.
Propel, of course, is an obvious choice. Immediately turned off by the use of Phing (the complexity and "magical" nature of which I don't particularly care for), I decided to push forward. I mean, so what if I don't like Phing. I only have to follow the, hopefully well written, instructions that come with Propel to get it is build using Phing, and then I should be done with it, right? Wrong.
Propel, for most intents and purposes, requires Phing. Propel users are strongly encouraged to use Phing as the build tool for their own applications and to integrate the Propel build process into the Phing process of their application. Even worse, their documentation doesn't seem to outline what happens during the Phing process with Propel so that a user could duplicate those tasks outside of Phing if one should choose to do so.
Placing so much dependence on something that supposed to be a "build tool" seems a bit obsurd. I mean, sure, almost every C application requires make, and make is a build tool. But, there isn't a whole lot of magic going on in a Makefile. I've never written a Makefile myself, but have easily and happily edited many a Makefile to correct or alter the installation behavior of a package. Additionally, it's easy enough to understand what the Makefile is trying to do, and duplicate those same actions on the command line yourself, should you choose to do so. But, in most cases, even that "feature" of make isn't really needed because, 9 times out of 10, you just want to build it the way it is setup by default, which means you just type make and you're done with it.
Most libraries and applications that I've installed before now have installed easily by following the instructions. The Makefile, whether for a library or an application, simply builds the package and places it in a proper location. With Propel, it doesn't seem to work quite this way. Each new use of Propel in a project will most likely require a new build process to take place in order to set Propel up for that project. It's not like any other library or class I've ever used, where you merely include the pieces you need and access the API presented by those pieces. Instead, Propel builds code to suit your needs. Well, not really. Actually, Phing builds the code that uses the Propel API to suit your needs.
So, I figured, despite the lack of documentation on how to use Propel without Phing, there must be a way. And by examining the generated classes and configuration files produced by building a Propel application with Phing should give me enough insight to be able to accomplish the task without Phing in the future. So, I went for it.
The documentation on the Propel website and the seemingly "proper" way to handle building a set or Propel classes seems to differ greatly, so I tried both.
First, I intended to install Propel once and then allow any application to access those libraries. So, intent on leaving the Propel installation pristine, I copies the example files for the "bookstore" out of the Propel distribution and into a new directory called fpropel. Then I tried to follow the directions in the Propel User Guide.
Since I copied the example source, I skipped the "Describing yout Database in XML", "Setting Build Properties", and "Setting Runtime Properties" sections, and went straight to "Building".
~/fpropel$ phing -Dproject=bookstore Buildfile: build.xml does not exist!
Ooookay. Obviously, I didn't copy enough. A search through the installed files only shows one file named "build.xml" and it was part of the Phing install. Ooookay, let's try what seems to be the "proper" way.
~/fpropel$ propel-gen ./
[... snip ...]
[phingcall] Calling Buildfile
'/usr/local/share/pear/data/propel_generator/build-propel.xml'
with target 'sql-template'
propel > sql-template:
[phingcall] Unable to store properties: Error writing property
file: Cannot fopen
/usr/local/share/pear/data/propel_generator/build/sql/sqldb.map
failed to open stream: Permission denied
[... snip ...]
propel > convert-props:
[echo] +------------------------------------------+
[echo] | |
[echo] | Converting project properties file to an |
[echo] | array dump for run-time performance. |
[echo] | |
[echo] +------------------------------------------+
[capsule] Using templatePath:
/usr/local/share/pear/data/propel_generator/templates
[capsule] Generating to file
/usr/local/share/pear/data/propel_generator/build/conf/${project}-conf.php
[capsule] Parsing control template: conf/Control.tpl
Execution of target "convert-props" failed for the following
reason:
/usr/local/share/pear/data/propel_generator/build-propel.xml:383:12:
Cannot write parsed template: Property file does not exist:
.//runtime-conf.xml
[phingcall]
/usr/local/share/pear/data/propel_generator/build-propel.xml:383:12:
Cannot write parsed template: Property file does not exist:
.//runtime-conf.xml
BUILD FINISHED
Ummmm. Why is it trying to write files in /usr/local/share/pear/data/? Since I'm not trying to build a small project as the "root" user, obviously, this is going to fail. Okay… fine… whatever. Let's forget about keeping the Propel install pristine and run this as root, allowing it to write where ever the hell it wants, even if I'm never able to find it again.
~/fpropel$ su
Password:
fpropel# propel-gen ./
[... snip ...]
propel > convert-props:
[echo] +------------------------------------------+
[echo] | |
[echo] | Converting project properties file to an |
[echo] | array dump for run-time performance. |
[echo] | |
[echo] +------------------------------------------+
[capsule] Using templatePath:
/usr/local/share/pear/data/propel_generator/templates
[capsule] Generating to file
/usr/local/share/pear/data/propel_generator/build/conf/${project}-conf.php
[capsule] Parsing control template: conf/Control.tpl
Execution of target "convert-props" failed for the following reason:
/usr/local/share/pear/data/propel_generator/build-propel.xml:383:12:
Cannot write parsed template: Property file does not exist:
.//runtime-conf.xml
[phingcall]
/usr/local/share/pear/data/propel_generator/build-propel.xml:383:12:
Cannot write parsed template: Property file does not exist:
.//runtime-conf.xml
BUILD FINISHED
Soooo. It got further, but still found the same error, which has to do with runtime-conf.xml. Okay… let's find it. Um… wait. It's sitting in the directory that I'm in. It's one of the files I copied over as part of the "bookstore". The error message seems to be saying that it's looking in ".//" for runtime-conf.xml which leads me to believe the the current working directory must have changed. Well… okay… let's hardcode a path if we can find mention of the runtime-conf.xml in any of these build files. Nope… we can't. Well, the only other build file the process seems to use the the Propel generator's build.xml. I don't really want to change that, but, what the hell. Hmmmm, nope. Again no runtime-conf.xml mentioned.
Okay… here's another idea. The first attempt at running Phing as suggested in the User Guide failed because build.xml couldn't be found. Well, maybe it's talking about the Propel Generator's build.xml. I'll copy it into this directory too and try again.
$ phing -Dproject=bookstore
Buildfile: /home/revjim/fpropel/build.xml
propel-project-builder > projdircheckExists:
propel-project-builder > projdircheck:
[echo] =====================================================
[echo] Project directory not specified or invalid. You must
[echo] specify the path to your project directory and your
[echo] project directory must contain your build.properties
[echo] and schema.xml files.
[echo]
[echo] Usage:
[echo]
[echo] $> propel-gen /path/to/projectdir [target]
[echo]
[echo] =====================================================
Execution of target "projdircheck" failed for the following reason:
/home/revjim/fpropel/build.xml:44:448:
No project directory specified.
BUILD FAILED
/home/revjim/fpropel/build.xml:44:448:
No project directory specified.
Okay. That's a start. Let's pick a project directory. Hmmm… well.. looking at build.xml seems to indicate that the project directory is specified on the command line. But I know that won't work with the phing command line… ahh… hell.. let's try it anyway.
~/fpropel$ phing -Dproject=bookstore ./ Buildfile: /home/revjim/fpropel/build.xml BUILD FAILED Target './' does not exist in this project.
~/fpropel$ phing ./ -Dproject=bookstore Buildfile: /home/revjim/fpropel/build.xml BUILD FAILED Target './' does not exist in this project.
Ok… so… let's try our buddy propel-gen again.
~/fpropel$ propel-gen ./ [... snip ...]
It's bitching about not being able to write in the proper directory, again. Okay… once again as root then.
~/fpropel$ su
Password:
fpropel# propel-gen ./
[... snip ...]
propel > convert-props:
[echo] +------------------------------------------+
[echo] | |
[echo] | Converting project properties file to an |
[echo] | array dump for run-time performance. |
[echo] | |
[echo] +------------------------------------------+
[capsule] Using templatePath:
/usr/local/share/pear/data/propel_generator/templates
[capsule] Generating to file
/usr/local/share/pear/data/propel_generator/build/conf/${project}-conf.php
[capsule] Parsing control template: conf/Control.tpl
Execution of target "convert-props" failed for the following reason:
/usr/local/share/pear/data/propel_generator/build-propel.xml:383:12:
Cannot write parsed template: Property file does not exist:
.//runtime-conf.xml
[phingcall]
/usr/local/share/pear/data/propel_generator/build-propel.xml:383:12:
Cannot write parsed template: Property file does not exist:
.//runtime-conf.xml
BUILD FINISHED
Yeah. So. I give up. Thanks Propel.
