Digital Fashion - Coding

About the self keyword in static methods

Geoffrey — Mon, 14 Jul 2008 16:04:00 +0200

While setting up a test server for some software I wrote at the office, I eventually noticed the following notice:

Notice: Use of undefined constant self - assumed 'self'

That surprised me, because 1) I though self were some kind of "superglobal" constant or a special token of the parser, always automatically available in a static method and 2) the code works. So what's up in there ? Let's make a simple test:

<?php

class foo {
	static public function bar() {
		var_dump(is_callable(array('self', 'foobar')));
		var_dump(is_callable(array(self, 'foobar')));

		var_dump(class_exists('self'));
		var_dump(class_exists(self));

		self::foobar();
	}

	static public function foobar() {
	}
}

foo::bar();

Executing the above code will yeld the following result:

bool(true)

Notice: Use of undefined constant self - assumed 'self' in /home/geoffreyb/test.php on line 6
bool(true)
bool(false)

Notice: Use of undefined constant self - assumed 'self' in /home/geoffreyb/test.php on line 9
bool(false)

What do we learn here ? Not much actually. It seems like self as a constant is only available when used with the scope resolution operator, aka double-colon or paamayim nekudotayim. When you want to use it in, for example, a callback definition, use a string representation of self:

<?php

is_callable(array('self', 'bar'));
call_user_func(array('self', 'bar'));

Which, while making absolutely no sense at all, works. Another way to get around this is to use the get_class() function that, without any argument, will return the name of the class you're currently in (foo in my example).

After a bit more investiging, I found out that there is nothing special about the self token, which is actually a string token. You can check this very easily with the following code:

<?php

class foo {
	static public function bar() {
		self::foobar();
	}
}

var_dump(token_get_all(file_get_contents(__FILE__)));

Somewhere inside the output, you'll find the following piece of text:

  array(2) {
    [0]=>
    int(307)
    [1]=>
    string(4) "self"
  }

And the token id 307 is resolved by token_name to string.

Zend Framework 1.5.1 PEAR package is available

Geoffrey — Mon, 31 Mar 2008 17:08:00 +0200

A little late sorry, but ZF 1.5.1's package is now ready.

ruby: url_to_constant

Geoffrey — Thu, 27 Mar 2008 23:04:00 +0100

A small bit of ruby to get a constant from an URL:

require 'uri'

def url_to_constant(url)

        return URI.parse(url).host.gsub(/^www\./, '').capitalize.gsub(/[^a-z][a-z]/i) { |m| m.gsub(/[^a-z]/, '').upcase }.constantize

end

Nothing exceptionnal here, just a pretext to post something.

Zend Framework 1.5 PEAR package is available

Geoffrey — Sat, 22 Mar 2008 18:19:00 +0100

The long awaited 1.5 version of the Zend Framework has landed for some days already, and here comes its pear package. Please note the api version changed to 1.5 in this package.

Plugin "related by tags" pour dotclear 2, deuxième

Geoffrey — Mon, 10 Mar 2008 21:48:00 +0100

Après de longs mois d'attente, le related by tags nouveau arrive enfin ! Au menu des réjouissances, une interface de configuration, ainsi qu'un widget font leur apparition. Vous disposez donc désormais de deux manières d'afficher les billets liés, directement en modifiant le template comme avant:

{{tpl:include src="_related_by_tags.html"}}

ou tout simplement en activant le widget correspondant, que vous pouvez configurer comme vous l'entendez. Bien sur, ce widget ne s'affichera que lors de la visualisation d'un billet.

Au chapitre des fonctionnalités / bugfix manquant(e)s, on notera le bug lié à l'utilisation de postgresql, ainsi que la traduction française, qui sera pour plus tard.

Encore une fois, n'hésitez pas à poster tous vos commentaires ici même.

Zend Framework 1.0.4 PEAR package is available

Geoffrey — Wed, 27 Feb 2008 11:17:00 +0100

The package for the last 1.0.x release, 1.0.4, is now available on the phpmafia pear channel. Please report any issue in the comment of this post. The Zend_Locale's xml bug should now be fixed (they are now considered as php and thus put at the right place, which is not the best way to fix the bug I guess but at least it should work for now).

yaml, activerecord and acts_as_nested_set

Geoffrey — Sun, 02 Dec 2007 16:41:00 +0100

I used to use this yaml_to_ar lib from christophe to load categories tree into my database, using acts_as_tree in the model that was perfect. Arrived the time when I felt the need to use acts_as_nested_set instead, for which I had to fill the lft and rgt columns. So I just rewrote the yaml_to_ar piece of code (put this in lib/yaml_to_ar.rb):

require 'yaml'



class YAML_to_AR



  def initialize(file, model)

    @data = File.open(file) { |yf| YAML::load( yf ) }

    @model = model

  end



  def process(data = @data, parent = nil)

    if data.is_a? Array

      data.each do |val|

        process(val, parent)

      end

    elsif data.is_a? Hash

      data.each do |key,val|

        parent = @model.create(:title => key)

        process(val, parent)

      end

    elsif data.is_a? String

      parent.add_child(@model.create(:title => data))

    end

  end



 end

This should handle both acts_as_tree and acts_as_nested. To ease things a bit further, I also wrote a rake task (to drop in lib/tasks/db_load_categories.rake for example):

namespace :db do

  desc "Loads categories defaults data"

  task :load_categories => :environment do

    require 'lib/yaml_to_ar'

    Category.delete_all

    categories = YAML_to_AR.new('db/categories.yml', Category)

    categories.process

  end

end

Now I just rake db:load_categories, and voila !

my first rails plugin: named_resources

Geoffrey — Wed, 28 Nov 2007 13:00:00 +0100

It's a simple plugin (2 lines of code beside class and modules declarations) which allows routes created via the map.resources mechanism to be customized. Say you have the following map:

map.resources :members

It will generate routes like:

/members
/members/:id
/members/new

No say you want to i18n your app, in french for example, what do you do ? You just can't out of the box. This is where my plugin enters into action, just add a :route_name parameter to the map.resources call and you're set:

map.resources :members, :route_name => 'utilisateurs'

will generate routes like:

/utilisateurs
/utilisateurs/:id
/utilisateurs/new

It shall also work for nested resources, although I did not test that.

The code is actually pretty simple:

module ActionController

  module Resources

    class Resource

      def path

        route_name = @options.include?(:route_name) ? @options[:route_name] : @plural

        @path ||= "#{path_prefix}/#{route_name}"

      end 

    end 

  end 

end

To install just use script/plugin:

script/plugin install http://tools.assembla.com/svn/riskle/rails/plugins/named_resources

or to install as an svn:external resource:

script/plugin install -x http://tools.assembla.com/svn/riskle/rails/plugins/named_resources

Accessing raw post data in a controller

Geoffrey — Wed, 21 Nov 2007 12:03:00 +0100

For some reason, $HTTP_RAW_POST_DATA does not seem to be set inside an action controller. You'll have to use the php://input stream wrapper to access raw http post data:

$raw_post_data = file_get_contents('php://input');

Extending Zend_Controller_Router_Route: the singleton problem.

Geoffrey — Mon, 05 Nov 2007 14:37:00 +0100

Today I ran into an issue while extending Zend_Controller_Router_Route. I wanted to add a little path pre/post processing in the match() and assemble() methods, so I just extended the Route class to add my tiny bits of code into the methods. Except it did not work at all. After a few debuging, it turned out that the Router uses Zend_Controller_Router_Route::getInstance() to retrieve a route object, which uses a new self(); statement to instantiate the route object. Problem is that self always refers to the current class definition we're in, if the method is called from a child class, without being overloaded, self will refer to the wrong class.

Example:

class Foo {

        public static function getInstance() {

                return new self;

        }

}



class Bar extends Foo {}



var_dump(Bar::getClass());

echoes something like:

object(Foo)#1 (0) {
}

Which is fscking wrong IMHO. A quick workaround is to overload the getInstance method, which is what I call pretty annoying as it does not follow the DRY principle.

How I use the Zend Framework

Geoffrey — Mon, 22 Oct 2007 13:39:00 +0200

Having started a few applications using the Zend Framework, I came out with a few practices that I tend to use over and over. In this post I'll quickly expose some of them and explain why I do things the way I do them. As you'll notice, most of them are already widely known and used over the ZF developer's community. Please remember that these practices are just what I do, and come with no garanty at all to be best practices.

Directory structure

First thing to work out when starting a new Zend Framework powered application, at least if you decide to use the ZF's MVC component, is the application's directory structure. Here is the one I used, which is a slightly modified version of the official recommended structure. This is essentially a standard modular structure with all directories needed to store various additional data from your application.

application/
	cache/
	config/
		application.ini
		routes.ini
	data/
	layouts/scripts/
	library/App/
	logs/
	modules/
		default/
		user/
document_root/
	css/
	images/
	index.php
	js/

As you can see, I have many directories, each dedicated to a specific file type. This has many advantages, such as always knowing where to find what you're looking for or easily process files of a certain type (think grep foo logs/*). Also, I name my directories explicitly. I used to call the config directory etc, which is the directory holding most configurations files under UNIX systems, but it may not appear that clear to non-UNIX user, while config is clear enough for everyone.

Another point you might notice is the that all applications files and data are placed outside the document_root. This is done to avoid unwanted access to such resources. While this is the best way, in my opinion, to do, it may not always be possible (like when you have no control on your actual DocumentRoot. In this case, you may consider having the following structure:

application/
	cache/
	config/
		application.ini
		routes.ini
	data/
	layouts/scripts/
	library/App/
	logs/
	modules/
		default/
		user/
	tasks/
css/
images/
index.php
js/

Then you can deny any web access to the application/ directory with the following htaccess rules:

<Directory application>
    Order allow,deny
    Deny from all
</Directory>

Did you say modular ?

Yeah, I said it actually. Modules in Zend Framework are groups of controllers (along with their corresponding views and models) which sits in their own namespace. One could argue that module's primary goal is to ease code re-use, but I personnaly dunno, as I personnally still have not seen such a use of modules. The drawbacks of re-usable code is that it needs to be abstract enough to fit ant particular situation or so. In this context, I only have a single separate module alongside the default one: the user module. It has Index and Auth controllers, respectively used to perform CRUD and login/logout operations.

Having re-usable modules implies that all modules containes its own models, or at least, knows where (ie, in which other module) to find its required models. There comes Xend's model loader. This is an action helper which ease the load of models inside controllers, like:

$this->_helper->modelLoader(array('MyCoolModel', 'MyOtherModel'));

Easy heh ? The bad point with this helper is that it is restricted to, or at best tricky to use outside, action controllers. That is why I developped my own library loader which I shall present in another blogpost soon.

Models naming convention

Using the Xend's model loader trained me to adopt what I consider a good model naming convention, basically, it just follows the controller's conventions, that is, prefix the model name with the module's name, so that for example my user model is named like User_Users (the first User is the module name, the second Users is the ucfirst'ed tablename). whenever I need to have row specific model I just postfix the whole model name with _Row. It gives the following directory architecture:

modules/user/models/
	Users/Row.php
	Users.php

I'll eventually load User_Users_Row from User/Users.php with a simple require:

require_once dirname(__FILE__).'/Users/Row.php';

Personal library namespace

A recurring question from ZF beginners is to know where they should put their own library classes. The answer is pretty simple actually. You just create your own library namespace alongside Zend's. Let's say you wish to extend Zend_Db_Table_Abstract to add your own logic. The first thing to do is to choose the name of your namespace, we will use Foobar as an example, because this is a cool name. Your class will be named like Foobar_Db_Table_Abstract, and located in Foobar/Db/Table/Abstract.php, which in turn should be located anywhere in your include_path. So you could have the following directory structure:

application/library/
	Zend/
	Foobar/
	Riskle/

Just remember ZF's naming convention: from the filename, strip the .php, replace slashes (/) with underscores (_), and you've got the class name. Simple heh ?

App_ library namespace (App_Controller_Action, etc)

Additionnaly to my personal library namespace, I also have a special App namespace, which I always locate into application/library/App. This namespace principally provides two classes, App_Controller_Action and App_Db_Table_Abstract, which basically extend respectively Zend_Controller_Action and Zend_Db_Table_Abstract. All my controllers and models then use the App_ namespace as a reference, so that I can easily change the base class for all my controllers / models as easily as changing the parent of the corresponding App class.

Using third party components

Using ZF compatible components is just easy as dropping them in your include path. By ZF compatible, I mean following the ZF class naming convention. Just make source it's in your include_path, and you can start using them right away. Components library I use includes:

Xend's layout component
Some components from Naneau's library
My own library, Riskle (you'll need an assembla account)

I put them in a particular path (~/share/php/) which I add to my include path.

note: Some dikdiks tend to store third-party in application/library/ instead of a completely separate place. This problem looks a lot like dynamically linked vs static binaries. With static binaries (in our case, storing all in application/library/), you don't have to care about dependencies, as every single needed line of code is shipped with your application. This ease redistribution and installation a lot, but makes your download larger. You also have to manage yourself dependencies upgrade (which in turn save this hassle from the end-user). With dynamically linked applications, you avoid duplicated code by forcing the use of a global, site wide, code repository (generally /usr/share/php on unix systems). You also transfer dependencies handling to the end-user (and/or the packaging system). Really, this is a choice to make yourself I think.

Things get a little bit more complicated when the components does not follow the naming convention. What I do in this case is just puting them into a separate directory tree called vendor/, which I don't forget to add to my include path of course, then I just manually includes need files. We could have done a one-to-one match between the component's public classes and custom well-named classes, but it's much of a hassle for the benefit I think.

That's all folks !

Well that's all for today. I'll try to write some more in the future about application building with the Zend Framework, there are still a lot of things to be said, invented, and discovered :-)

Plugin "related by tags" pour dotclear 2

Geoffrey — Thu, 04 Oct 2007 20:50:00 +0200

update: nouvelle version disponible

Allez hop, j'ai codouillé rapidement aujourd'hui un plugin dotclear 2 pour afficher une liste des billets ayant le ou les mêmes tags que le billet en cours de lecture par l'internaute. Il est téléchargeable dès maintenant sous forme d'archive tar gzipée ou directement de package dotclear. Pour l'utiliser, rien de plus simple, il suffit d'ajouter le tag suivant dans votre template, à l'endroit où vous souhaitez afficher la liste des billets:

{{tpl:include src="_related_by_tags.html"}}

Et voilà c'est tout :-)

Bon par contre, il faut faire gaffe a comment on tag ses billets (genre pour celui là j'ai preferré ne pas le taguer php histoire d'avoir des résultats plus pertinents).

ps: si quelqu'un connait un moyen d'éviter d'avoir a rajouter un bout de code au template je suis preneur (mais j'ai la flemme de chercher là tout de suite).

PDO not throwing an exception when it should

Geoffrey — Mon, 01 Oct 2007 17:40:00 +0200

Today I ran into an issue that I already ran into a few weeks ago when I did not have time to dig up, but today I had this time (this plus it's a really annoying issue as you'll see). The main symptom is that PDO does not throws exceptions when you'd expect it to. It's very annoying. The reason, in my case, seems to be that I am querying an old mysql (3.23.x in my case but any 4.x will do according to this bug report). I was not able to find any info from google, so I'm posting this here so that people know :-)

New home for pagination component documentation

Geoffrey — Mon, 01 Oct 2007 12:44:00 +0200

For those caring, I just posted some quick documentation for the pagination component at my assembla space. More docs will follow (including extensive phpdoc docblocks I hope).

Zend Framework 1.0.2 PEAR package is available

Geoffrey — Sun, 30 Sep 2007 16:21:00 +0200

A PEAR package for the 1.0.2 version of the Zend Framework is now available from the PEAR PHPMafia channel. As usual, to install just issue the following:

pear channel-discover pear.phpmafia.net

pear install phpmafia/Zend

Bugfixes release of Zend Framework pagination component

Geoffrey — Sun, 30 Sep 2007 01:28:00 +0200

I just released on riskle's assembla space a new version of my pagination component for the Zend Framework which you can download right now:

Riskle Paginate r122

This release fixes a nasty bug in Riskle_Db_Table::fetchCols which prevented from retrieving the right count of cols involved in the query.

The table component has also been slightly rewritten following Erik's suggestion to move the parent mapping into _fetch. The parent mapping itself has been improved to allow "multi level" table joining. This will be best explained with an example:

Say you have three table, Foo, Bar and Quux, and you would like to execute the following query:

SELECT * FROM Foo JOIN Bar ON Foo.bar_id = Bar.id JOIN Quux ON Bar.quux_id = Quux.id

This is now possible with the following mapping (in Foo's class of course):

array(

    'Bar' => array('local' => 'bar_id', 'remote' => 'id'),

    'Quux' => array('local' => 'quux_id', 'remote' => 'Quux.id'),

);

Easy heh ?

As usual, any comments are appreciated, and please note that this code is released under the same license as the ZF itself, the new-bsd license.

Of controller plugins and directory layout

Geoffrey — Sun, 23 Sep 2007 00:55:00 +0200

When anyone on #zftalk ask about where controller plugins should be kept, we usually responds something like have your own library namesapce alongside Zend/ and put it in it like YourNamespace/Controller/Plugin/YourPlugin.php. But what about application specific controllers ? There's a time where you have to write a plugin that relies on the application at such a level that using it elsewhere would make no sense. In that case, where can we store this plugin ? The question arised this morning, and we ended up to the fact that having a controller-level plugin directory would not hurt, after all. So one could have the following directory layout (simplified on purpose):

/application/modules/default
    /controllers
    /library/Plugin
        MyPlugin.php

The drawback is that in order to use autoload you would have to have each modules Plugin dir in the include path, which is a bit of a hassle. Instead, we could have the much more simple folloing layout:

/application
    library/Controller/Plugin
        MyPlugin.php

Which is simpler but does not allow for modules specific plugins. Anyway, the former layout would require a bit more logic in the bootstrap in order to extract every modules path as plugins are registered pre-dispatch.

Hope it helps with directory layout organization :-)

UPDATE

What I've finally decided to do is the following:

/application
    library/App/Controller/Plugin
        MyPlugin.php

So that application specific code gets prefixed with the App_ namespace.

Zend Framework Pagination, third strike

Geoffrey — Sun, 23 Sep 2007 00:07:00 +0200

UPDATE: new version (r105) available.

The component was given a little rewrite as expected, but maybe a little bit later than I would have wanted to :-) So it now has its own Rowclass proxy from which you can pull various infos such as current page, page range, next page, etc all exposed as getter methods (that is, getCurrentPage, getPageRange, getNextPage, etc), which you won't really have to worry about since the brand new view helper will take care of that for you. Usage has changed a little, bit, so let's first have a look at what's happening from the controller point of view:

$table = new Riskle_Db_Table_Paginate(new Table, $this->_getParam('page'));

$this->view->rowset = $table->fetchAll();

Not much changed here, except we don't need anymore to call getPaginationInfos(). Nice ! Now the big part, the view:

$this->paginate($this->rowset);

echo $this->paginate()->previous();

echo $this->paginate()->navigation();

echo $this->paginate()->next();

The view helper uses the neat composite helper trick from naneau - which is a really cool trick, great job naneau my fellow no-more-a-bunny. The first call inits the helper, feeding him the necessary rowset to work on, then you just have to call the methods you need to draw the navigation links. As you may expect, previous and next method will return nothing if no page is available (actually, they return their second argument, which defaults to an empty string).

Also, it's worth noting that the bundled Riskle_Db_Table features the patch from Erik, as well as a totally rewritten fetchCols method (now uses a straight Zend_Db_Select object instead of the ugly trick it used to use).

My code is no longer available on subversion, I moved the project to assembla. Instead ou can download this component from the riskle space's files board (direct download), the file contains all classes needed for the component to work, just unzip it in your include_path and you're set.

As usual, any comments are more than welcome.

Riskle_Form, a quick wrapup

Geoffrey — Wed, 19 Sep 2007 16:12:00 +0200

So well, I've been busy these days working on my own implementation of a form component in the ZF spirit. This post is to help me see where I'm at with this component, as well as planning future evolution. I'll try my best to describe what it does and does not, and what it could do in the future.

Of course, while this is more of a personnal pense-bete than anything else, any comments are welcome.

Basic features

Forms are build using the factory, which ensures each form has a unique name so that two forms can't conflict when used on the same action. Each element of the form is materialized by an instance of Riskle_Form_Element which holds any configuration directive for the element.

Prototyping

The component features an extensible prototyping system via the Riskle_Form_Prototype set of class. Default (and mandatory atm) is to use a Zend_Config_Ini file which can in turn contains further prototyping instructions, such as prototype from a model (by model I mean a class extending Zend_Db_Table). A given form can embed multiple prototypes, possibly of the same type, which have to be conretized before the form is usable. Concretization of form operates in a FILO merging fashion. Prototyping from a model is for the moment very basic, it treats all fields as text field, but this will be addressed in time. Of course, the system allows for different source of prototyping (think Riskle_Form_Prototype_Xml for example).

Form elements

Elements features a variety of configuration directives, which I'll details here.

type: explicitly tells the type of the field (for the moment, better tell an existing HTML type). default is text.
label: basically, the string to be put into the <label /> tag.
validators: an array of validators, see Data validation for details.
allow_empty: weither the field is allowed to be empty or not.
datasource: specify a datasource to retrieve the field datas from (only used for <select /> fields). See below for further details about that.
depends: specify a field to which the current field is dependent. Mainly used for auto-ajax-refreshing <select />.

The datasource directive deserves a little more explanation. When the form factory encounters a datasource directive, it delegates the work to the datasource factory, which autodetects and decode the datasource. The core distributions handles the following datasources:

Instanciated Model, with format: YourModel->method
Static Model, with format: YourModel::method
CSV string, with format: csv:foo,bar. It uses a user land CSV decoder that will most likely be bundled with the core distribution when (if ?) released.
JSON string, with format: json:{'foo', 'bar'}. It's worth noting that this example will be converted to the following associating array: array('foo' => 'foo', 'bar' => 'bar'). You can avoid this by including a noassoc switch (so that it reads json:noassoc:{'foo', 'bar'}. Another note on JSON: the main problem when allowing JSON in INI files is that you can't have a double quote character in values (except by using a dirty hack which I do not want), and the php json decoder expects identifiers to be doublequoted. The datasource handles this by replacing any non escaped single quote to a double quote.

Data validation

Data validation is done by a subclassed Zend_Input_Filter. validators configuration from elements should conform to ZFI syntax. The custom Riskle_Form_Input component features a getRaw set of methods to retrieve raw data (used in case the form was not successful). Not much else to say here.

Rendering

The core distribution features a set of view helper aimed at easing html form drawing. The helpers use the built-in ZF view helpers to render fields while adding a bunch of custom markup around (namely: labels and error messages). The default helpers also take care of fields that depend on other fields (see Form elements) and add the according ajax queries to populate the element.

Workflow control

The most interesting part I think. Riskle_Form features a plugin system, much like the Zend_Controller one. It exposes the following hooks (in this order):

formStartup, always run at the beginning of the workflow
prePopulate, run before the form gets it data (either from the model or the request)
postPopulate, run after the form gets it data
preValidate, run before the forms attempts to validate the data
onValidateSuccess, run if and only if the data validation was a success
onValidateFailure, run if and only if the data validation was a failure
postValidate, run after the forms attempts to validate the data (regardless of the success or not)
preCommit, run before the form tries to feed the model with the data
onCommitSuccess, run if and only if the data feedage was a success
onCommitFailure, run if and only if the data feedage was a failure
postCommit, run after the forms tries to feed the model with the data (regardless of the success or not)
formShutdown, always run at the end of the workflow

For each hook, the instance of the current form is passed as an argument to the method. Of course, the commit set of hooks will only be run if the data validates.

Sample usage

A simple uploading form could look like the following:

$form = Riskle_Form::factory(new Zend_Config_Ini('upload.ini', null));

$form->registerPlugin(new Riskle_Form_Plugin_Upload('myUploadField'));

$form->run();

$this->view->assign('form', $form);

the view would look like:

echo $this->drawForm($this->form);

and upload.ini could look like:

[form]

model = "uploaded_files"

prototype = 1



[fields]

myUploadField.type = "file"

myUploadField.label = "choose an image"



legend.type = "text"

legend.label = "Legend"

What it lacks

Clearly, this form component is designed for use in an HTML component. Few or no care has been taken to ensure cross-medium compatibiliy such as XHTML, PDF, etc. Hopefully the changes to apply to achieve such compatibility will not be that much of a hassle. While I'm not willing to ensure such a compatibility, I'd be happy to apply any patch submitted.

Regarding plugins, they still miss the ability to really act on the workflow, such as stopping it, skipping steps (?) or add errors to the stack, etc.

Also, the code still needs a few refactoring and optimization, especially regarding the view helpers and the main form class, as well as the configuration file syntax which needs an in-depth revision.

findBy{$Field} with Zend_Db_Table

Geoffrey — Tue, 14 Aug 2007 14:01:00 +0200

A quick post to show how one can easily implement a findByField wrapper in Zend_Db_Table:

/**

         * Implements a simple findByField wrapper

         */



        public function __call($method, $args) {

                if (preg_match('/^findBy([a-zA-Z0-9]+)$/', $method, $parts)) {

                        $field = strtolower(preg_replace('/([a-z])([A-Z])/', '$1_$2', $parts[1]));

                        if (!in_array($field, $this->_cols)) {

                                throw new Zend_Db_Table_Exception(sprintf('\'%s\' field not in row', $field));

                        } else {

                                $db = $this->getAdapter();

                                $where = $db->quoteInto($db->quoteIdentifier($field).' = ?', $args[0]);

                                return $this->fetchAll($where);

                        }

                }

        }

What it does is basically trapping any non-existant method call and check if the corresponding field exists, after converting CamelCasing to underscore_notation (eg: FooBar becomes foo_bar).